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I. 


INTRODUCTION 


• A study  of  the  remote  batch  marketplace  was  conducted  during  May 

and  June,  1975,  to  meet  the  specific  needs  of  three  major  remote  computing 
service  companies.  It  was  structured  and  executed  to  make  the  results 
applicable  to  other  companies  in  the  industry  facing  the  same  critical 
decisions.  This  report  contains  the  results  of,  and  conclusions  from, 
the  study  effort. 

• The  objectives  of  the  study  were  to  identify  opportunities  with 
significant  revenue  potential  within  the  remote  batch  (R/3)  computer 
services  market  and  to  develop  the  information  essential  to  the 
preparation  of  a business  plan  to  take  advantage  of  these  opportunities. 

In  particular  the  study  examined: 

- Current  and  future  nature  of  the  remote  batch  services 
markets 

- Technical  requirements  to  compete  in  these  markets 

- Marketing  requirements  to  compete  in  these  markets 
Competitors  in  the  markets,  their  revenues,  approaches  and 
plans. 
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• Care  has  been  taken  from  the  initial  design  of  the  study  through 
to  the  final  preparation  of  the  report  to  make  the  information  produced 
directly  usable  by  managers  responsible  for  marketing,  market  and 
financial  planning,  and  technical  development  within  companies  in  the 
remote  computing  services  industry. 

• To  identify  market  opportunities  interviews  were  conducted  with 
computer  service  vendors,  computer  service  users,  and  leading  edge  computer 
users  who  do  not  use  services  in  order  to: 

- Analyze  and  evaluate  the  current  and  future  market  from  a 
variety  of  perspectives, 

- Analyze  and  evaluate  the  current  and  future  markets  for 
different  variations  of  remote  batch  services,  and 

- Develop  useful  competitive  information  designed  to  complement 
that  information  which  is  generally  available. 

• To  develop  necessary  business  plan  inputs,  in-depth  interviews  were 
conducted  with  current  users  of  remote  batch  services  to  determine: 

A wide  variety  of  detailed  technical  requirements, 

- Communications  needs  related  to  terminal  speeds  and  network 
utilization,  and 

A broad  range  of  essential  marketing  information  relating  to 
users'  attitudes  and  desires. 

• The  report  is  based  upon  the  authors'  previous  experiences  plus  an 
analysis  of  interviews  designed  and  conducted  primarily  by  telephone 
expressly  for  this  study.  The  interview  base  was: 
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Scientific  and  engineering  R/B  users  15 
Business  applications  R/B  users  17 
Users  of  remote  computing  services  7 
Timesharing  only  service  users  6 
Federal  government  R/B  users  5 
Miscellaneous  R/B  related  users  5 
Remote  computing  service  vendors  10 
Other  A 

Total:  69 


• With  the  exception  of  some  of  the  interviews  (which  were  conducted 

by  computer  industry  professionals),  the  work  herein  is  the  product  of 

/ 

Peter  A.  Cunningham,  President  of  INPUT,  a market  research  and  consulting 
organization,  and  Robert  B.  Field,  a self-employed  consultant  to  the 
computer  services  industry.  Both  men  have  had  extensive  and  successful 
experience  within  the  computer  services  industry  as  well  as  significant 
experience  conducting  market  research  projects  of  this  type. 
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II  SUMMARY  AND  KEY  FINDINGS 


A,  REMOTE  BATCH  MARKETS  - CURRENT  AND  FUTURE 

• Remote  Computing  Services  Market  Growth. 

Remote  batch  market  will  grow  from  $280  million  in  1975  to 
$890  million  in  1980. 

- Interactive  market  will  grow  from  $700  million  in  1975  to  $1900 
million  in  1980. 

Data  base  market  will  grow  from  $120  million  in  1975  to  $U50 
million  in  1980. 

• The  real  growth  in  remote  computing  services  is  in  markets  with  mixed 
interactive /remote  batch  components. 

• Scientific  and  Engineering  (S  & E)  Remote  Batch  Market. 

- Will  grow  from  $130  million  in  1975  to  $320  million  in  1980 

- Two  thirds  of  the  user  expenditures  are  from  very  large  companies 
with  extensive  in-house  capabilities. 

- Average  account  size  is  significantly  larger  (maybe  by  a factor 
of  2)  than  business  accounts. 

- There  is  a smaller  requirement  for  an  interactive  component  than 
with  the  business  sector. 
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Business  Remote  Batch  Market. 

- Will  grow  from  $110  million  in  1975  to  $440  million  in  1980. 

- One  segment  of  the  business  market  is  computer  substitution  for 
medium  and  small  companies:  this  fast  growing  segment  is  the  most 
secure  of  the  remote  batch  markets. 

- The  other  segment  is  supplemental  applications  processing  to 

enhance  in-house  capability:  this  is  the  least  secure  of  the 

remote  batch  markets. 

- Both  segments  have  significant  interactive  component  requirements. 

Federal  Government  Remote  Batch  Market. 

- Will  grow  from  $Uo  million  in  1975  to  $130  million  in  1980, 
dependent  on  policy  determinations. 

- The  new  GSA  contract  will  not  damage  CSC  and  will  cause  other 
vendors  to  the  federal  government  to  give  similar  substantial 
discounts . 

- Not  all  remote  computing  procurements  will  be  covered  by  the 
contract;  vendors  with  specialized  services  need  not  obtain  a 
GSA  contract. 

Sources  of  Remote  Batch  Expenditures. 

- User  expenditures  are  primarily  for  new  applications. 

- There  is  little  use  of  proprietary  vendor  programs. 

- No  evidence  of  significant  conversion  of  timesharing  to  remote 
batch  or  of  overflow  processing  was  found. 

- 6 - 


INPUT 


Of  applications,  modelling  and  simulation  is  important  to  business 
and  scientific  users. 

The  small  users  are  companies  in  high  technology  or  growth 
environments  which  need  some  access  to  a large  computer. 


B.  COMPETITIVE  ENVIRONMENT 

• Competitive  vendor  groups: 

- Spinoffs  are  the  predominant  remote  batch  vendors  with  1*3#  of  the 
market,  and  their  importance  will  increase*. 

- Computer  manufacturers,  with  the  exception  of  CDC  in  the  S & E 
market,  are,  and  will  continue  to  be,  minor  participants. 

- Independents'  market  share  will  grow  from  only  32#  as  timesharing 
companies  start  to  offer  remote  batch  and  multi-mode  services. 

(*  Figures  do  not  include  spinoffs  'captive'  revenues  from  their  parent 
companies) . 

• Revenues  generated  on  IBM  mainframes  account  for  almost  half  the  total 
remote  batch  market  and  this  proportion  will  increase  due  to  the  growth 

of  the  IBM-oriented  business  remote  batch  market. 


C.  MARKETING  REQUIREMENTS 

• Why  users  select  to  use  remote  batch  services: 

- Service  users  with  in-house  computers  are  buying  special  hardware 
or  software. 
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- Service  users  with  no  or  small  in-house  capability  are  buying 
the  most  economical  approach. 

- Increases  will  come  from  variety  of  growth  factors;  decreases  will 
come  primarily  from  in-house  conversion. 

- Non-users  don't  use  because  they  feel  they  have  the  capability 
in-house,  but  might  use  for  proprietary  software  or  overload 
relief. 

How  vendors  are  selected: 

- Prime  considerations  are  hardware  type  and  price. 

- Also  important  are  the  service  factors:  reliability,  turnaround, 
and  user  support. 

- Less  important  are  vendor  provided  applications,  network  availa- 
bility, and  user  proximity  to  vendor  hardware. 

- Users  will  switch  vendors  if  their  performance  on  the  service 
factors  (reliability,  turnaround,  and  user  support)  deteriorates 
from  present,  generally  satisfactory,  levels. 

Pricing  considerations: 

- Assuming  similar  services,  the  average  user  will  require  a 23l 
price  difference  to  switch  vendors. 

- Terms  and  conditions  vary  through  a variety  of  special  arrangements. 

- Users  have  few  ideas  about  pricing  but  like  quantity  discounts 
and,  under  some  conditions,  long  term  contracts. 

- Users  expect  remote  batch  to  cost  about  half  as  much  as  time- 
sharing. 
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The  decision-makers: 


Two-thirds  of  the  affirmative  decision-makers  were  other  than 
chief  D.P.  manager. 

80#  of  the  negative  decision  makers  were  the  chief  D.P.  managers. 

• Field  personnel  requirements: 

— Relatively  little  technical  support  required,  generally  agreed 
to  be  less  than  for  timesharing. 

- Sales  people  should  possess  technical  knowledge,  empathy,  and 
honesty. 

D.  TECHNICAL  REQUIREMENTS 

• Compatibility  requirements  of  current  users: 

- Two-thirds  of  users  have  strong  preference  for  particular 
mainframe  type. 

- Less  than  half  of  users  have  strong  preference  for  particular 
operating  system  and  most  of  them  are  business  users. 

- Few  users  have  requirements  for  a particular  DB/FM  system, 
special  systems  features,  or  special  hardware. 

• Current  typical  scientific  job  characteristics: 

- 32 OK  bytes  of  core,  large  amount  of  execution  time. 

- Small  files,  small  I/O. 

- Two- thirds  of  jobs  require  turnaround  of  less  than  2 hours. 

— Various  jobs  submitted  dally  or  many  times  per  week. 


• Current,  typical  business  job  characteristics: 

- 90K  bytes  of  core,  moderate  amount  of  execution  time. 

- Small  to  medium  files,  moderate  I/O. 

- One  third  of  jobs  require  turnaround  of  less  than  2 hours. 

- Various  jobs  submitted  daily  or  many  times  per  week. 

• Data  communications  requirements: 

- Only  one  third  of  current  users  require  multi-city  network,  and 
the  network  need  not  be  sophisticated. 

- Terminal  speeds  will  increase  some;  96OO  baud  will  satisfy  almost 
all  requirements. 

- Almost  all  users  access  remote  batch  services  via  local  dial  or 
leased  line  which  is  frequently  managed  by  the  vendor. 

E.  STRATEGIES  AND  OPPORTUNITIES 

• General  Recommendations: 

- All  remote  computing  services  vendors  must  develop  an  integrated 
remote  batch  and  interactive  capability. 

- Remote  batch  vendors  should  emphasize  the  business  market,  but 
not  exclude  the  scientific  and  engineering  market. 

- Remote  batch  vendors  should  integrate  the  use  of  intelligent 
terminals  into  their  product  line. 

- Remote  batch  vendors  must  have  a strong  data  base  handling 
capability. 

- Sales  efforts  should  be  aimed  at  new  users  rather  than  replacement 
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selling. 

- 'Service'  is  of  prime  importance  to  remote  batch  users; 
'reliability'  is  more  important  than  in  timesharing. 

- Sales  personnel  must  be  user/applications  oriented. 

Scientific  and  Engineering  Market. 

- Vendors  in  this  market  should  emphasize  state-of-the-art 
developments  including  advanced  graphics  features. 

- Vendors  in  this  market  should  apply  their  sophisticated  tools  to 
the  solution  of  business  problems  requiring  large  scale  computing. 

- These  vendors  should  enhance  the  file  handling  and  I/O  capabilities 
of  their  equipment  to  match  business  users  needs. 

Business  Market. 

- Vendors  should  offer  IBM-based  services  for  maximum  market 
penetration. 

- The  main  target  market  should  be  computer  substitution  to  companies 
in  the  $10  million  - $50  million  annual  revenue  range  in  high 
technology  and/or  growth  industries. 

- In  order  to  penetrate  this  market,  vendors  should  acquire  a 
comprehensive  set  of  standard  business  software  and  problem- 
solving tools. 

- Computer  substitution  and  industry  intensive  sales  require 
separate  marketing  and  sales  forces. 
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Federal  Government  Market. 

- This  market  offers  significant  business  opportunities  but  at  a 
relatively  high  entry  cost  and  with  substantial  discounts. 
Vendors  should  carefully  compare  the  opportunities  in  this 
market  with  those  in  other  markets. 
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Ill  THE  REMOTE  BATCH  MARKETS  - CURRENT  AND  FORECASTED 


The  remote  computing  services  market  in  1975  has  three  major 
components : 

• Interactive/Timesharing  - characterised  by  interaction  of  the  user 
with  the  system,  primarily  for  problem-solving  timesharing,  but  also  for 
data  entry  and  transaction  processing:  the  user  is  •on-line'  to  the 
program/ files . 

• Remote  Batch  - where  the  user  hands  over  control  of  a job  to  the 
computer,  which  schedules  job  execution  according  to  priorities  and 
resource  requirements. 

• Data  Base  Inquiry  - characterised  by  the  retrieval  of  information  from 
a vendor  maintained  data  base. 

The  components  are  not  easily  distinguishable  in  many  cases:  the 
borders  between  them  are,  in  fact,  becoming  less  distinct.  For  example, 
deferred  timesharing  runs  have  been  available  for  several  years  on  most 
major  timesharing  companies,  together  with  the  option  to  use  high  speed 
printers  at  the  vendors'  local  offices  for  volume  output.  Vendor  revenues 
for  a deferred  run  could  be  classified  under  'timesharing'  (where  the  job 
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initiated)  or  'remote  batch'  (the  manner  in  which  it  was  performed),  or 
split  between  the  two  categories.  For  the  purposes  of  this  analysis  we 
allocate  them  between  the  two.  We  estimate  between  5#  and  10#  of 
'timesharing'  vendor  revenues  are  derived  from  'deferred  run*  or  remote 
batch  activities. 

The  breakdown  between  the  market  components  are  shown  in  Exhibit  III-l. 
Growth  rates  in  the  market  shown  in  Exhibit  III-2  are  dependent  on  a number 
of  factors : 

• The  economy  - growth  rate  in  remote  computing  in  1975  will  be  only 
15#  compared  to  a normal  30#  because  of  the  impacts  of  the  recession. 

There  is  a lag  time  of  approximately  3 months  between  user  decisions  and 
the  impact  on  vendor  revenues.  Therefore  the  first  quarter  of  1975  has 
seen  continued  fairly  high  growth  rates.  The  slowdown  will  be  apparent 
in  the  second  quarter  financial  performance.  More  normal  growth  will 
resume  in  1976. 

• The  impact  of  minicomputers  will  be  felt  mainly  from  1978  onwards: 
this  is  discussed  later  in  the  report.  Suffice  to  say  that  the  minis,  will 
take  over  the  interactive  component  for  many  large  remote  batch  services 
with  significant  interactive  expenditures.  They  will  also  convert  some 
production-oriented  timesharing  to  mini,  processing. 

• Remote  batch  in  the  scientific  and  engineering  problem  solving  area 
will  expand  at  a 15#  - 20#  rate.  Faster  growth  will  be  in  the  trans- 
action processing  market  for  both  business  and  scientific  and  engineering 
applications.  However,  this  applications  dependent  business  is  a longer 
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EXHIBIT  III-l 


INTERACTIVE 

REMOTE  BATCH 

DATA  BASE 
INQUIRY 


INTERACTIVE 

REMOTE  BATCH 

DATA  BASE 
INQUIRY 


INTERACTIVE 

REMOTE  BATCH 
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INQUIRY 

TOTAL:  19 7 ^ 

1975 


REMOTE  COMPUTING  SERVICES  EXPENDITURES 


1975 
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1500 

2000 
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MILLION 

$1,100  MILLION 

1980 

$3,240 

MILLION 

- 15  - 


INPUT 


EXHIBIT  III-2 


REMOTE  COMPUTING  SERVICES  GROWTH  RATES 
(IN  %)* 


1975 

1976 

1977 

1978 

1979 

1980 

INTERACTIVE 

15 

25 

26 

23 

22 

15 

REMOTE  BATCH 

12 

21 

2h 

31 

29 

26 

DATA  BASE 

20 

33 

38 

32 

28 

22 

TOTAL 

15 

25 

27 

26 

23 

19 

•1975  FIGURE  ■ (12I5=i9li)  iqoJK 
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sales  lead  time  and  effort  compared  with  problem-solving  timesharing. 
Consequently  its  growth  rate  will  lag  initially.  However,  the  combination 
of  minicomputers  and  remote  computing  services  will  provide  for  large 
account  growth  in  the  late  1970s. 

• The  need  for  information  of  all  kinds  appears  insatiable.  Consequently 
data  base  services  will  be  the  fastest  growing  segment  of  the  market.  Any 
industry  which  has  a 'broker'  arrangement  will  require  data  bases  to 
support  the  business:  also  government  regulation  will  be  a major  factor  in 
the  establishment  and  use  of  data  bases.  These  data  bases  will  also  lead 

to  major  timesharing  revenues  as  users  process  data  from  the  data  bases 
through  their  own  models.  A classic  example  is  the  use  of  the  Chase 
Econometrics  model  on  Cyphemetics : each  $ of  data  base  usage  has  $2  - $1+ 
of  associated  processing  of  users'  own  models.  Initially  the  saturation  of 
the  stock  quotation  market  dampens  the  growth  rate  in  this  sector. 

• The  reduction  in  communications  cost  and  the  need  for  voice  input/ 
output,  video,  graphics  and  other  features  will  insure  the  continued  growth 
of  the  interactive/timesharing  mode.  Mass  storage  devices  will  allow  for 
significant  reductions  in  storage  costs  of  files  with  sufficiently  fast 
access-times  to  satisfy  many  interactive  user  requirements.  Also,  the 
average  timesharing  account  size  of  $1000  per  month  will  not  be  sufficiently 
large  in  itself  to  attract  mini-replacement,  although  aggregate  amounts 
will  in  some  cases.  Similarly  relatively  expensive  intelligent  terminals 
will  only  be  affordable  for  larger  account  sizes;  thus  conversion  to  remote 
batch  will  not  be  feasible  in  many  cases.  As  interactive  terminals  become 
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cheaper,  the  threshold  will  be  lowered  for  new  and  existing  applications 
consequently  the  average  account  size  will  decrease  towards  the  average 
batch  service  bureau  account  size. 
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A. 


USER  EXPENDITURE  ANALYSIS 


The  remote  batch  and  interactive  markets  can  be  analyzed  also  by  the 
type  of  service  used  rather  than  by  the  mode  of  service  provided.  In  this 
regard  the  degree  to  which  remote  batch  and  interactive  are  separable 
from  the  users'  viewpoints  must  be  examined.  Exhibit  III-3  shows  that 
the  remote  batch/interactive  part  of  the  total  market  is  the  fastest 
growing  of  the  segments.  By  1978,  the  pure  remote  batch  and  pure  interactive 
markets  will  together  be  smaller  than  the  segment  where  both  modes  are  required. 

1.  BY  TYPE  OF  SERVICE 

• Scientific  and  Engineering  remote  batch  market  is  the  largest  service 
area  in  1975  as  shown  in  Exhibit  III-1+.  It  is  based  on  large-scale  CDC 
6000,  Univac  1100  and,  to  a more  limited  extent,  IBM  370  series  computers. 

Four  vendors,  CDC,  McAuto,  UCC,  and  UCS  account  for  60$  of  the  market. 

• Growth  in  the  S & E market  will  be  steady  rather  than  spectacular, 
averaging  15$  - 20$.  The  increasing  use  of  simulation  and  design  tools 
in  areas  such  as  pollution  control,  energy  usage,  construction,  and 
Defense  projects  will  be  a main  source  of  new  revenues.  Models  which  are 
concerned  with  the  way  a product  or  service  is  designed,  built  or  operated 
are  included  in  this  category. 

• In  the  remote  batch  business  market  the  two  subsegments  are: 

- computer  substitution  where  the  user  gets  all  or  nearly  all  its 
computer  processing  through  the  remote  computing  service.  The 
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EXHIBIT  III-3 


REMOTE  BATCH /INTERACTIVE  MARKET  COMBINATION 


PURE  INTERACTIVE 

PURE  REMOTE  BATCH 

REMOTE  BATCH/ 
INTERACTIVE  COMBINED 


PURE  INTERACTIVE 


PURE  REMOTE  BATCH 
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PURE  INTERACTIVE 

PURE  REMOTE  BATCH 

REMOTE  BATCH/ 
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$1900M 


500  1000  1500  2000 
($  MILLIONS) 


AFTER  1978,  REMOTE  BATCH  AND  INTERACTIVE  SERVICE  REVENUES 
WILL  BE  INSEPARABLE  IN  MOST  CASES. 
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EXHIBIT  III-1+ 
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SCI.  & ENG 
BUSINESS 
FED.  GOVT. 


SCI.  & ENG. 
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FED.  GOVT. 
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FED.  GOVT. 


REMOTE  BATCH  MARKET  BY  USER  TYPE 
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user  can  have  had  a computer  and  replaced  it  by  the  service  (as 
happened  with  5 of  the  survey  respondents)  or  started  and  grown 
with  the  services  concept  without  ever  having  an  in-house 
computer  (as  was  the  case  with  the  remaining  5 respondents  in 
the  business  area  without  a computer). 

NOTE:  This  borders  on  remote  facilities  management  but  is  not 

characterized  as  such  because  of  the  absence  of  long  term  contracts 
and  management  factors. 

- Applications  processing,  where  the  user  buys  remote  batch  services 
for  particular  applications  to  supplement  its  own  in-house 
capability.  In  this  area,  the  business  analytical  type  of  appli- 
cation is  very  important:  such  applications  are  financial  and 
market  modelling,  scheduling,  and  sales  analysis.  The  establish- 
ment of  business  data  bases  for  analysis  and  network-based  data 
collection  are  also  included  in  this.  The  remote  batch  portion  of 
primarily  interactive  applications  services,  such  as  those  offered 
by  XCS,  NCR,  Keydata,  National  Data,  and  TRW,  are  included  here 
together  with  remote  batch  applications  services  such  as  are 
offered  by  OSI  and  MMDS.  The  remainder  of  the  market  is  derived 
from  custom  user  programs. 

Growth  of  the  various  subsegments  of  the  business  remote  batch  market 
is  shown  in  Exhibit  III-5. 

• The  federal  government  market  is  discussed  separately. 
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EXHIBIT  III-5 


BUSINESS  REMOTE  BATCH  MARKET  GROWTH 


($  MILLIONS) 


BA  = BUSINESS  ANALYSIS 

TP  = TRANSACTION  PROCESSING 

DB  » DATA  BASE  CONSTRUCTION  AND  USE 
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2 


BY  INDUSTRY 


• For  the  scientific  and  engineering  remote  batch  market  the  prime 
using  industries  are: 

- electric  power  utilities  - engineering  design  and  nuclear  codes; 

- electrical  and  electronics  industries  - simulation  and  circuit 
design; 

- aerospace  manufacturers  - structural  analysis; 

- engineering  research  and  design  organizations; 

- process  manufacturers  - oil  companies  for  rig  design  and  modelling. 

There  is  also  deferred  run  business  which  generally  parallels  the 

interactive  market. 

• For  the  business  remote  batch  market,  there  are  a wider  variety  of 
user  industries: 

- computer  substitution  is  particularly  successful  where  the  user 
has  need  of  limited  access  to  a large  computer  but  can't  afford 
it  in-house.  Such  industries  as  state  and  local  government, 
manufacturing  (including  metal  parts  and  pharmaceutical), 
professional  organizations,  service  companies  such  as  architectural 
and  engineering  companies,  hospitals  and  other  users  of  medical 
data  bases  contain  such  users. 

- applications  processing  includes  particular  network  oriented 
applications,  such  as  order  entry  and  labor  distribution,  in 
manufacturing  and  wholesaling.  Large  data  base  handling  with 
requirements  for  ad  hoc  reporting  are  common  in  the  utilities, 
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manufacturing,  banking,  government  and  research  industries. 

3.  BY  COMPANY  SIZE 

• The  scientific  and  engineering  remote  batch  market  is  dominated  by 
the  aerospace,  utility,  and  large  equipment  manufacturing  users.  Conse- 
quently two-thirds  of  the  market  is  with  very  large  organizations  as 
shown  in  Exhibit  III-6.  Significant  revenues  come  from  research  and 
development  organizations,  engineering  companies,  and  advanced  technology 
based  companies  in  the  small  and  medium-sized  categories. 

• The  business  remote  batch  markets,  on  the  other  hand,  lie  heavily 
with  the  medium  and  small  company  through  the  provision  of  complete  data 
processing  capabilities  or  through  the  provision  of  applications  beyond 
the  scope  of  the  in-house  group  to  develop  or  operate,  for  example  PICS 
or  order  entry. 

• In  the  business  area,  divisions  of  medium,  large  and  very  large 
companies  are  often  serviced  as  small  independent  entities,  particularly 
when  the  parents  lack  the  resources  to  devote  to  their  offsprings'  data 
processing  needs.  In  the  survey,  h of  the  users  fall  into  this  category. 

• In  banking,  two  'vendors'  were  interviewed  which  provided  bank  data 
processing  to  over  100  small,  correspondent  banks.  These  vendors  were 
both  subsidiaries  of  bank  holding  companies.  This  market  is  basically 
'captive*  and  unavailable  for  open  competition.  To  a certain  extent,  it 
is  open  to  joint  venture  approaches,  such  as  those  of  BCS,  MMDS,  and 
Computeri sties,  or  can  be  taken  over,  as  with  National  Sharedata. 
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EXHIBIT  III-6 
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B.  RANGE  AND  DISTRIBUTION  OF  ACCOUNT  SIZES 


• Average  account  size  was  $20K  per  month  for  scientific  and  engineering 
users  surveyed,  compared  with  $10K  per  month  for  business  respondents. 

As  shown  in  Exhibit  III— 7 the  range  of  account  size  is  significantly 
different  as  well,  with  the  scientific  and  engineering  group  having 
almost  k0%  of  respondents  with  expenditures  over  $20K  per  month  compared 
with  only  about  10#  for  business  respondents. 

• In  the  limited  sample,  the  distribution  of  federal  government  agency 
expenditures  more  closely  paralleled  the  scientific  and  engineering  users. 

• There  was  no  significant  difference  in  account  size  when  examining 
the  respondents  purely  on  the  basis  of  whether  or  not  they  had  an  in-house 
computer,  as  shown  in  Exhibit  III— 8.  However,  there  is  some  indication 
that: 

- business  users  with  in-house  computers  spend  less  (about  $6K  per 
month  on  average)  than  business  users  without  a computer  (about 
$11K  per  month  on  average); 

- scientific  users  with  in-house  computers  spend  more  (about  $23K 
per  month  on  average)  than  similar  users  without  a computer 
(about  $13K  per  month  on  average). 

• Of  11  respondents  giving  indications  of  197*+  expenditures,  one  was 
spending  the  same  amount  in  1975  and  one  was  spending  less:  the  average 
increase  was  32#  for  the  remaining  respondents,  with  the  exception  of  one 
respondent  which  went  from  $0  to  $50K  - $100K  per  month. 
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EXHIBIT  III-7 


ACCOUNT  SIZE  BY  USER  TYPE 
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EXHIBIT  III-8 


ACCOUNT  SIZE  BY  COMPUTER  STATUS 
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• 50#  of  respondents  will  increase  their  expenditures  in  1976  and  27# 
expect  to  remain  the  same,  as  shown  in  Exhibit  III-9. 

- The  average  account  size  of  the  business  respondents  will 
increase  from  $10K  per  month  to  $12K. 

- The  average  account  size  for  scientific  and  engineering  respon- 
dents will  increase  from  $20K  to  $22K  per  month. 

- In  the  government,  the  largest  single  user  among  all  the 
respondents  will  go  in-house,  reducing  $2  million  per  year  of 
remote  batch  expenditures  with  GSA/INFONET  to  $0  eventually. 

• The  most  exposed  remote  batch  services  revenues  come  from  business 
users  with  in-house  computers:  several  indicated  they  would  take  the 
business  in-house.  As  shown  in  Exhibit  III-10,  for  all  respondents  with 
in-house  computers,  there  was  an  even  distribution  of  account  growth 
intentions  for  next  year  and  three  years*  time.  Contrasted  with  this, 
respondents  without  computers,  heavily  favored  account  growth  in  their 
replies,  with  an  average  overall  increase  for  1976  of  30#. 
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EXHIBIT  III-9 


ACCOUNT  GROWTH  BY  USER  TYPE 
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EXHIBIT  III-10 


ACCOUNT  GROWTH  BY  COMPUTER  STATUS 
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c. 


SOURCE  OF  REMOTE  BATCH  EXPENDITURES 


• In  the  following  exhibits  the  percentage  responses  from  users  have 
been  tabulated  without  regard  for  account  size.  We  assume  that  differences 
among  account  size  will  not  significantly  alter  the  findings. 

• 'New  applications'  are  the  prime  source  of  remote  batch  expenditures, 
accounting  for  over  60%  of  use  as  shown  in  Exhibit  III-ll.  The  next 
largest  category  was  conversion  from  in-house  computers  and  accounted  for 
27%  of  use.  Other  sources,  including  conversion  from  timesharing,  were 
relatively  small. 

• As  expected,  business  respondents  indicated  the  highest  rate  for 
conversion  from  in-house  batch  (over  h0%) $ however,  the  amount  of 
scientific  and  engineering  converted  from  in-house  to  remote  batch  was 
also  significant  ( 16% ) and  appeared  to  be  due  to  turnaround  and  similar 
problems  with  internal  operations. 

• Also  as  expected,  new  applications  will  account  for  a greater  share 
(70%)  of  the  use  in  future,  with  conversion  from  batch  in-house  dropping 
to  20%.  Again,  however,  there  is  no  indication  of  significant  conversion 
from  timesharing.  In  the  users'  minds,  it  appears  these  are  two  very 
distinct  services  at  the  moment. 

• As  shown  in  Exhibit  III-12,  there  is  a minimal  amount  of  overflow 
processing,  as  such.  However,  there  is  a significant  amount  of  conversion 
from  batch  in-house  for  those  respondents  with  computers,  as  well  as  for 
those  where  services  replaced  in-house  computers.  This  portion  of  the 
remote  batch  revenues  is  probably  highly  transitory. 
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EXHIBIT  III-ll 


SOURCE  OF  REMOTE  BATCH  SERVICES  USE 
BY  USER  TYPE 


USER  TYPE  & SOURCE 

CURRENT  SHARE 

FUTURE  SHARE 

WEIGHT* 

WEIGHT* 

SCIENTIFIC  & ENGINEERING 

a)  CONV.  FROM  BATCH  SERVICE  BUREAU 

105 

50 

b)  CONV.  FROM  TIMESHARING 

26 

50 

c)  CONV.  FROM  BATCH  IN-HOUSE 

245 

200 

d)  NEW  APPLICATIONS 

1099 

700 

e)  & f)  OVERFLOW  & OTHER 

25 

0 

BUSINESS 

a) 

20 

105 

b) 

65 

65 

c)  (AS  ABOVE) 

730 

330 

d) 

845 

900 

e)  & f) 

40 

0 

FEDERAL  GOVERNMENT 

a) 

50 

30 

b) 

40 

30 

c)  (AS  ABOVE) 

40 

0 

d) 

300 

300 

e)  & f) 

70 

50 

•ACCUMULATED  PERCENTAGES  FROM  RESPONSES  TO  THE  QUESTION  'WHAT  PER  CENT 
OF  YOUR  CURRENT/FUTURE  R/B  SERVICES  USAGE  WOULD  YOU  CHARACTERIZE  AS: 
LIST  a)  THROUGH  f)  AS  TABULATED. 
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EXHIBIT  III-12 


SOURCE  OF  REMOTE  BATCH  SERVICES  USE  BY  COMPUTER  STATUS 


COMPUTER  STATUS  AND  SOURCE 

CURRENT  SHARE 
WEIGHT* 

FUTURE  SHARE 
WEIGHT* 

RESPONDENTS  WITH  AN  IN-HOUSE 

COMPUTER 

a)  CONV.  FROM  BATCH  SERVICE  BUREAU 

135 

15 

b)  CONV.  FROM  TIMESHARING 

76 

50 

c)  CONV.  FROM  BATCH  IN-HOUSE 

435 

295 

d)  NEW  APPLICATIONS 

lUl9 

1090 

e)  & f)  OVERFLOW  & OTHER 

135 

50 

RESPONDENTS  WITHOUT  AN  IN-HOUSE 

a) 

l+O 

125 

b) 

55 

35 

c)  (AS  ABOVE) 

580 

235 

d) 

825 

810 

e)  & f) 

0 

0 

* ACCUMULATED  PERCENTAGES  FROM  RESPONSES  TO  THE  QUESTION  'WHAT  PER 
CENT  OF  YOUR  CURRENT/FUTURE  R/B  SERVICES  USAGE  WOULD  YOU  CHARACTERIZE 
AS:  LIST  a)  THROUGH  f)  AS  TABULATED  . 
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D 


NATURE  OF  REMOTE  BATCH  PROCESSING  SERVICE 


1.  ON-LINE  COMPONENT 

• The  comment  was  made  by  one  respondent  that  ’remote  batch  without 
timesharing  capability  is  obsolete’.  The  same  user  also  stated  that 
probably  80$  of  timesharing  could  be  deferred  without  too  many  compaints. 

• As  shown  in  Exhibit  III-13  there  is  a major  difference  between 
business  users  and  scientific  and  engineering  users  in  their  use  of  on-line, 
interactive  components  with  remote  batch  services.  In  future,  respondents 
reported  that  almost  half  the  use  in  the  business  area  will  require  an 
on-line  interactive  capability. 

• As  shown  in  Exhibit  III-lU,  there  does  not  appear  to  be  a clear  diffe- 
rence between  those  respondents  with  an  in-house  computer  and  those  with- 
out, except  that  those  with  a computer  expect  a greater  on-line  component 
in  future.  However,  the  sample  response  is  so  varied  (6  respondents  in 
the  group  replied  100*  pure  batch  and  3 replied  0 % pure  batch)  that  conclu- 
sions drawn  from  this  would  be  unreliable.  There  is  some  indication  the 
wide  variation  is  application  related. 

2.  REMOTE  DATA  ENTRY/REMOTE  JOB  ENTRY 

• Almost  all  the  scientific  and  engineering  work  involves  remote  job 
entry,  as  shown  in  Exhibit  III-15.  In  business,  certain  applications  use 
remote  data  entry:  usually  this  is  collected  from  various  points  by  the 
vendor  in  a data  base,  using  the  user's  own-coded  programs.  This  portion 
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EXHIBIT  III-13 


REMOTE  BATCH  USE  WITH  INTERACTIVE  COMPONENT  BY  USER  TYPE 


USER  TYPE 

CURRENT  USE  WITH 
INTERACTIVE  COMPONENT 

FUTURE  USE  WITH 
INTERACTIVE  COMPONENT 

SCIENTIFIC  & 
ENGINEERING 

9% 

19% 

BUSINESS 

hl% 

bl% 

FEDERAL 

GOVERNMENT 

21% 

35% 

TOTAL 

26 % 

35% 

(AVERAGE  % REPORTED  BY  RESPONDENTS) 
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EXHIBIT  Ill-lit 


REMOTE  BATCH  USE  WITH  INTERACTIVE  COMPONENT 
BY  COMPUTER  STATUS 


USER  STATUS 

CURRENT  USE  WITH 
INTERACTIVE  COMPONENT 

FUTURE  USE  WITH 
INTERACTIVE  COMPONENT 

RESPONDENTS 
WITH  AN 
IN-HOUSE 
COMPUTER 

29 % 

U 3 55 

RESPONDENTS 
WITHOUT  AN 
IN-HOUSE 
COMPUTER 

22% 

2 It  % 

(AVERAGE  % REPORTED  BY  RESPONDENTS) 


- 38  - 


INPUT 


EXHIBIT  III-15 


REMOTE  JOB  ENTRY/REMOTE  DATA  ENTRY  USE  BY  USER  TYPE 


USER  TYPE 

CURRENT  RJE  USE 

FUTURE  RJE  USE 

SCIENTIFIC  & 
ENGINEERING 

95% 

9Q% 

BUSINESS 

Q2% 

19% 

FEDERAL 

GOVERNMENT 

1^% 

Q2% 

TOTAL 

86 % 

90% 

(AVERAGE  OF  REPORTED  PERCENTAGE  OF  RJE  USE) 
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of  the  market  will  grow  rapidly  with  the  growth  of  special  applications 
processing. 

3.  DATA  BASE/FILE  MANAGEMENT  REQUIREMENTS 

• Over  50#  of  current  users  do  not  require  a DB/FM  language  of  any  kind, 
as  shown  in  Exhibit  III— 16.  However,  four  respondents  did  indicate  they 
were  totally  dependent  on  a data  base  system  such  as  IMS. 

• As  expected,  business  respondents  used  data  base/file  management 
systems  more  heavily  than  the  scientific  and  engineering,  and  federal 
government  respondents. 

• As  shown,  there  will  be  an  increasing  use  of  DB/FM  systems,  but  it 
will  be  a gradual  increase.  One  reason  could  be  the  overhead  which  the 
users  would  be  required  to  pay  for.  Many  of  these  users  are  very  cost 
conscious  and  will  avoid  unnecessary  frills. 
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EXHIBIT  III-16 


DATA  BASE/FILE  MANAGEMENT  REQUIREMENTS  BY  USER  TYPE 


PERCENTAGE  OF  R/B  SERVICES  USING  DB/FM 

USER  TYPE 

0 % 

156-25  f 

26%-5o; 

5156-75:6 

l6%-ioo% 

CURRENT  USE 

SCIENTIFIC  4 
ENGINEERING 

10 

3 

2 

BUSINESS 

8 

3 

2 

k 

(All  100$) 

FEDERAL 

GOVERNMENT 

2 

2 

1 

TOTAL 

20 

8 

5 

k 

FUTURE  USE 

SCIENTIFIC  & 
ENGINEERING 

7 

2 

2 

BUSINESS 

6 

3 

1 

k 

FEDERAL 

GOVERNMENT 

l 

2 

2 

TOTAL 

Ik 

k 

7 

1 

k 

(NUMBER  OF  RESPONDENTS  BY  CATEGORY) 
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E. 


APPLICATIONS  ANALYSIS 


1.  VENDOR /USER  SUPPLIED 

• There  was  little  use  of  vendor  supplied  software  in  the  survey,  as 
shown  in  Exhibit  III-17.  In  the  S & E market,  most  of  the  vendor  supplied 
software  is  actually  in  the  public  domain  through  the  federal  government 
(NAS TRAN,  for  example)  or  through  -universities  working  on  federal  grants. 

• There  was  little  identifiable  trend  to  the  use  of  vendor  supplied 
applications  software,  by  these  respondents.  In  future,  however,  there 
will  be  a definite  trend  for  new  users  to  be  attracted  by  vendor  software. 
Also,  clients  of  applications  specialized  vendors  such  as  XCS,  Keydata, 
etc.,  were  not  interviewed  as  part  of  this  study  as  they  are  primarily 
on-line  users. 

2.  APPLICATIONS  USED 

• In  S & E,  building  models  and  using  simulation  tools  together  make 
up  the  major  demand  for  remote  batch  services  as  shown  in  Exhibit  III-18. 
Software  in  the  public  domain  is  used  for  nuclear  code  testing  and  large 
scale  structures  design.  Although  the  software  is  available,  most  users 
regard  it  as  more  economical  to  process  such  applications  on  a large 
scale  vendor  machine.  Many  of  the  applications  are  separable  so  the  user 
may,  and  often  does,  have  several  vendors. 

• The  business  market  is  more  prosaic,  with  standard  accounting, 
production,  and  labor  and  personnel  systems.  Over  60%  of  the  respondents 
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EXHIBIT  III-17 


USE  OF  VENDOR  SUPPLIED  PROGRAMS  BY  USER  TYPE 


USER  TYPE 

PERCENTAGE  OF  USE  OF  VENDOR  SUPPLIED  PROGRAMS 

CURRENT 

FUTURE 

SCIENTIFIC  & 
ENGINEERING 

3k% 

21% 

BUSINESS 

11% 

19% 

FEDERAL 

GOVERNMENT 

k% 

6% 

TOTAL 

20 % 

20% 

(AVERAGE  OF  RESPONDENT  PERCENTAGES) 
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EXHIBIT  III-18 


APPLICATIONS  USED  BY  RESPONDENTS 


USER  TYPE 

APPLICATION 

NO.  OF 
MENTIONS 

SCIENTIFIC  & 

PUBLIC  DOMAIN  - NUCLEAR  CODE 

k 

ENGINEERING 

" " - STRUCTURAL  ENG. 

k 

MODE IS 

6 

SIMULATION 

3 

DATA  REDUCTION/FILE  MANAGEMENT 

1 

LOAD  LEVELLING,  PROJECT  MONITORING 
CIRCUIT  ANALYSIS,  CHIP  DESIGN,  ENG.  DESIGN 

jl  EACH 

BUSINESS 

ACCOUNTING 

8 

PRODUCTION 

U 

LABOR  DISTN. /PERSONNEL/PAYROLL 

7 

PLANNING  & SCHEDULING 

k 

DATA  BASE /FILE  MANAGEMENT 

6 

ORDER  ENTRY 

3 

CITY  BUSINESS,  ENG.  APPNS.,  TRUST  ACCTG. 

) 

PROG.  DEVELOPMENT, CHECK  WRITING 

)1  EACH 

FEDERAL 

MODELS  & MNGMNT.  SCIENCE  TECHNIQUES 

3 

GOVERNMENT 

ENGINEERING  DESIGN 

1 

REMOTE  DATA  ENTRY  AND  DECENTRALIZED 

1 

PROCESSING  OF  INSURANCE  APPN. 
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were  primarily  using  these  applications.  Of  the  remainder,  data  base 
handling  was  important  to  a third  of  the  respondents.  Planning, 
scheduling  and  forecasting  were  also  key  applications  areas  for  about  25 % 
of  respondents.  In  several  cases,  this  involves  considerable  model 
building.  Remote  order  entry  was  used  by  three  respondents,  particularly 
from  remote  locations. 

• In  the  federal  government,  model  building  is  again  rated  highly  both 
for  S & E and  ’business'.  The  major  application,  in  terms  of  $ volume, 
is  an  insurance  package  to  support  mortgage  insurance:  the  annual 

contract  value  is  approximately  $2M,  but  it  is  going  in-house  on  a 
Univac  1108  when  a conversion  and  network  construction  project  is 
finished. 
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THE  FEDERAL  GOVERNMENT  MARKET 


1.  GSA  DEVELOPMENTS 

• The  ADP  Teleprocessing  Services  Contract  Program  being  developed 
by  GSA  to  cover  the  purchase  of  teleprocessing  services  by  federal 
agencies  is  planned  to  go  into  effect  on  January  1,  1976.  This  contract 
program  will  replace  the  GSA  contract  with  CSC/INFONET. 

- The  intent  of  this  program  is  to  expand  the  scope  of  authority 
of  GSA  in  the  purchase  of  teleprocessing  services  by  federal 
agencies. 

- It  will  bring  other  remote  computing  activities  than  those 
presently  covered  by  the  GSA/INFONET  contract  under  one  umbrella 
contract.  (At  present  use  of  CSC/INFONET  is  only  for  applications 
requiring  access  to  a data  base  from  more  than  one  geographic 
point  and  in  both  interactive  and  remote  batch  modes.) 

- It  is  an  attempt  to  obtain  pricing  discounts  of  20#  -30#  on  many 
of  the  services  currently  being  provided  to  federal  agencies 
outside  the  scope  of  the  CSC/INFONET  contract. 

• The  scope  of  the  contract  has  not  yet  fully  been  defined:  July  1 is 

the  target  for  release  of  the  final  solicitation  contract.  It  is  unlikely 
that  it  will  cover  the  provision  of  all  remote  computing  services  to  all 
agencies . 

- The  instructions  to  agencies  leaves  scope  for  them  to  award 
contracts  based  on  special  requirements. 
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The  key,  however,  is  that  waivers  will  have  to  be  obtained  from 
GSA  on  the  use  of  any  teleprocessing  (remote  computing)  service 
not  on  the  approved  list. 

• The  provisions  of  the  contract  are  such  that  large  agencies  notably 
DoD  and  HEW,  will  virtually  continue  to  do  as  they  wish.  Smaller  agencies 
will  be  'pushed  around'  more  by  GSA. 

• Vendors  with  unique  capabilities,  such  as  DRI,  are  better  off  staying 
away  from  the  contract.  They  will  still  be  able  to  sell  their  services 
and  not  give  the  discount. 

• There  is  some  slight  advantage  to  vendors  on  the  approved  list  in 
that  they  will  have  less  involvement  with  individual  agency  contracting 
officers;  in  other  words,  the  problems  of  persuading  the  individual  agency 
contracting  office  to  allow  a contract  after  the  technical  people  have 
been  sold  is  considerably  reduced.  This  is  offset  by  the  regomarole  the 
technical,  people  must  go  through  to  select  the  vendor  with  'the  least  cost'. 

• The  'benchmark'  provisions  are  extensive:  vendors  should  charge  for 
all  benchmarks  as  agencies  will  be  required  to  perform  them. 

• A contract  with  GSA  will  not  generate  any  revenues  in  itself.  The 

vendor  must  still  'sell'  individual  agencies:  the  concept  of  the  agencies 

'shopping  around’  for  services  is  untenable.  However,  by  1978  the  majority 
of  federal  government  remote  batch  expenditures  will  be  through  GSA  contract 
as  shown  in  Exhibit  III-19. 
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EXHIBIT  III-19 


TOTAL 


GSA 

CONTRACT 


TOTAL 


GSA 

CONTRACT 


* 

FEDERAL  GOVERNMENT  REMOTE  BATCH  MARKET 


($  MILLIONS) 
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2. 


AGENCY  REQUIREMENTS  AND  TRENDS 


• Although  individual  agencies  responding  to  the  survey  did  not  indi- 

cate a high  use  of  DB/FM  systems,  this  is,  and  will  be,  a major  require- 
ment in  future.  In  particular,  as  standards  are  developed  through  NBS 
and  ANSI,  the  federal  government  will  mandate  their  use.  In  the  meantime, 
IMS,  System  2000,  ADABAS,  CC204,  and  others,  are  being  acquired  by  most 
large  agencies:  implementation  of  systems  is  proving  a problem  however. 

• The  growth  of  government  responsibilities  and  the  expansion  restric- 
tions placed  on  individual  agencies  will  be  major  drivers  to  the  use  of 
outside  services.  Furthermore,  the  inability  of  ADP  groups  within 
agencies  to  respond  to  the  rapidly  changing  demands  will  also  cause  use 
of  outside  services.  Therefore  new  agencies  and  those  with  added  respon- 
sibilities are  prime  candidates  for  the  use  of  services. 

• The  government  requirements  for  reporting  continue  to  increase,  thus 
data  base  establishment  and  maintenance  to  support  federal  programs  is  a 
major  application  area.  In  conjunction  with  this,  the  need  for  ad  hoc 
reporting  requirements  to  meet  congressional,  public  interest  group,  and 
constituent  demands  for  information  is  increasing  rapidly.  Again,  in-house 
groups  are  not  geared  to  satisfying  these  demands. 

• Decentralization  of  programs  from  central  agency  offices  in 
Washington  will  continue  and  will  generate  needs  for  support  in  regional 
and  local  offices.  The  Housing  and  Urban  Development  mortgage  insurance 
business  reported  in  the  interviews  is  a classic  example  of  this.  The 
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large  scale  requirement  ($2  million  per  year)  has  caused  the  agency  to 
establish  its  own  network  to  support  the  application  and  bring  the  pro- 
cessing in-house.  Residual  processing  will  remain  with  the  vendor. 

e An  alternative  to  the  use  of  outside  remote  computing  services,  as 
such,  is  the  use  of  facilities  management,  such  as  the  contracts  OSI  has 
with  EPA  and  FEA,  or  CSC  has  with  NASA.  In  future,  agencies  will  tend 
to  use  the  EPA/FEA  approach,  whereby  the  vendor  operates  computers  for 
the  agencies  off-site,  as  opposed  to  the  older,  NASA  approach,  where 
the  computers  are  owned  by  NASA  and  operated  on-site.  In  many  cases 
the  border  between  facilities  management  and  remote  computing  will  be 
hard  to  determine.  GSA  will  undoubtedly  try  to  get  its  hands  on  the 
remote  FM  business  as  well. 

In  this  context,  NASA  stands  out  as  a government  agency  which  has 
performed  eminently  successfully,  in  large  part  due  to  its  contracting- 
out  policy  and  intelligent  use  of  computer  and  software  services. 


4 


4 


4 
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TECHNICAL  REQUIREMENTS 


INPUT 


t 
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IV . TECHNICAL  REQUIREMENTS 


A.  COMPUTER  MAINFRAMES 


Exhibit  IV-1  indicated  the  mainframes  types  in  use,  on  a remote 
batch  service  basis,  by  the  respondents.  After  a discussion  of  their 
current  and  planned  activities,  the  users  were  asked  if  they  required 
these  particular  mainframe  types.  Exhibit  IV-2  illustrates,  along  with 
other  factors,  the  users'  attachment  to  particular  mainframe  types. 

• More  than  two-thirds  of  the  users  responded  that  they  either  required 
or  had  a strong  preference  for  the  particular  mainframe(s)  which  they 
currently  used  for  remote  batch  services. 

• The  reasons  for  this  included: 

- Compatibility  with  in-house  systems 

- Special  hardware  characteristics  (such  as  60-bit  words) 

- Availability  of  programs  written  for  certain  systems  only 

- Cost  of  conversion  of  existing  programs 
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EXHIBIT  IV- 1 


REMOTE  BATCH  VENDOR * S MAINFRAME  TYPES  USED  BV  RESPONDENTS 


Computer 

!Tanufacturer 

System/Model 

Frequency 

Model 

Manufacturer 

IBM 

33 

370/195 

1 

360/85 

1 

370/165-168 

12 

370/155-158 

9 

360/65 

5 

370/145 

1 

Unknown 

4 

CDC 

6600-7600 

12 

UNIVAC 

1108 

9 

Burroughs 

Unknown 

1 

DEC 

PDP  10 

1 

G.E. 

Unknown 

1 

Total 

57 
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EXHIBIT  IV- 2 


CURRENT  HARDWARE/ SOFTWARE  REQUIREMENTS 


Particular 
mainframe  tvpe 


Particular 
operating  system 


Particular 
DB/FM  system 


Other  (system) 
software 


Other  hardware 
(e.g.,  COM,  PLOTTER) 
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0 There  was  no  significant  difference  in  attachment  expressed  by  the 
business  and  scientific  users  of  remote  batch  services.  In  other  words, 
the  ability  to  get  users  to  switch  mainframe  types  is  independent  of 
these  two  market  segments. 
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B. 


OPERATING  SYSTEMS 


Exhibit  IV-2  also  illustrates  the  users'  requirement  for  a particular 
operating  system.  Again,  after  a discussion  of  current  and  planned 
activity,  they  were  asked  if  they  required  a particular  operating  system. 

• Forty-one  percent  of  the  users  indicated  a requirement  or  strong 
preference  for  a particular  operating  system.  Hov/ever,  this  may  be  some- 
what misleading  since  many  respondents  indicated  a need  for  an  operating 
system  by  manufacturer  type  only.  That  is,  they  stated  that  they  required 
IBM  but  did  not  state  a requirement  for  either  OS,  VS,  or  VM  in  particular. 
OS  was  the  dominant  IBM  operating  system  in  use. 

• Reasons  for  operating  system  preference  were: 

Compatibility  with  in-house 

- Resistance  to  having  to  learn  a new  system 

- Procedural  and  program  incompatibilities  and  the  required 
conversions 

• The  scientific  users  were  more  willing  to  change  operating  systems 
than  were  the  business  users.  This  is  not  surprising  considering  business 
applications  generally  make  greater  use  of  operating  system  facilities 
and  tend  to  develop  file  dependencies. 
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c. 


OTHER  FEATURES 


Users  were  quite  independent  of  other  service  features.  Exhibit  IV-2 
illustrates  the  degree  of  dependency  upon  other  software  facilities  or 
special  hardware. 

• Eleven  percent  of  the  users  required  a particular  data  base  or  file 
management  system.  IMS  was  found  to  be  in  moderate  use  and  it  did,  of 
course,  create  such  a dependency.  Other  DB/FM  systems  were  also  in  use 
but  the  users  did  not  generally  feel  that  their  continued  use  of  those 
particular  systems  was  a requirement. 

• A small  number  of  users  expressed  a requirement  for  system  features 
other  than  those  mentioned  above.  TSO  was  mentioned  as  a requirement  by 
one  user. 

• Special  hardware  was  the  least  required  feature  by  the  users  surveyed. 
COM  was  frequently  in  use  but  there  was  no  requirement  for  the  remote  batch 
vendor  to  supply  it;  generally,  COM  conversion  was  done  in-house  or  by  a 
service  bureau.  Plotters  were  also  in  frequent  use  by  the  scientific  users 
but,  once  again,  they  did  not  require  the  vendor  to  provide  the  plotting 
facility.  In  both  cases  the  appropriate  software  routines  are  all  that 
the  remote  batch  services  vendor  need  support.  No  cases  of  mass  storage 
were  encountered  or  foreseen  by  the  users  surveyed.  Graphics  was  encount- 
ered with  one  user  and  foreseen  by  one  government  user. 
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D . PROGRAM  CHARACTERISTICS 


1.  CORE  REQUIREMENTS  TEND  TO  BE  LARGE 

Exhibit  IV— 3 illustrates  the  core  requirements  of  the  programs 
currently  run  by  users  of  remote  batch  services.  The  upper  figure 
depicts  the  typical  program;  the  lower  figure  depicts  their  largest 
programs.  Responses  were  converted  to  be  roughly  equivalent  to  IBM 
bytes  for  ease  of  reference. 

• Typical  programs  tend  to  be  large,  certainly  by  traditional  time 

sharing  standards,  with  almost  50%  of  them  exceeding  200K  bytes.  Of 
these  typical  programs,  only  about  on  in  five  occupied  less  than  100K 

bytes  of  core.  These  figures  reflect  the  core  requirements  when  (if) 

overlaid;  they  are  not  the  size  required  if  the  programs  were  written 
without  overlays. 

\ 

• The  average  typical  program  required  230K  bytes  of  core.  As  might 

be  expected,  business  users’  typical  core  requirements  were  less  than  those 
of  the  scientific  users.  The  typical  business  program  averaged  about  90K 

bytes;  the  typical  scientific  program  averaged  about  320K  bytes.  The  two 

largest  typical  scientific  programs  were  600K  and  HOOK  bytes;  with  these 
removed  from  the  sample,  the  average  for  typical  scientific  programs  is 
about  200K.  (Reference  Exhibit  IV-4.) 

• The  largest  programs  being  run  on  remote  batch  services  required 
substantial  amounts  of  core.  Almost  one— third  of  the  user's  largest 
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BYTES  (000' s)  BYTES  (000* s) 


EXHIBIT  IV- 3 


CORE  REQUIREMENTS  - TYPICAL  REMOTE  BATCH  PROGRAMS 
(AVERAGE  = 230K  BYTES) 


0-99 


100-199 


200-299 


300-499 


> 500 


21% 


7% 


10% 


34% 


28% 


H h 


10  15  20  25  30  35 

% of  Programs 


CORE  REQUIREMENTS  - MAXIMUM  REMOTE  BATCH  PROGRAMS 
(AVERAGE  = 612K  BYTES) 


0-256 


257-512 


513-768 


769-1024 


> 1024 


% of  Programs 
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EXHIBIT  IV-4 


AVERAGE  CORE  REQUIREMENTS 
REMOTE  BATCH  PROGRAMS 


Nature  of  Use 

Typical  Program 

Largest  Program 

Business 

90K 

245K 

Scientific  & 

320K 

885K 

Engineering 

Combined 

230K 

612K 

Average 
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programs  require  in  excess  of  one-half  million  bytes  and  two-third's 
require  more  than  one-quarter  million  bytes.  Again,  this  is  the  require- 
ment when  overlaid. 

• The  average  maximum  core  requirement  was  612IC  bytes.  Once  again, 
there  was  a great  discrepancy  between  the  requirements  of  the  business 
and  scientific  users.  Business  users'  maximum  program  size  averaged 
almost  250K;  scientific  users'  maximum  program  size  average  almost  900K. 
(Reference  Exhibit  IV-4.) 

2.  FILE  SIZES  RANGE  WIDELY  BUT  TEND  TO  BE  SMALL 

Users  found  the  questions  about  file  sizes  difficult  to  answer. 

Often  this  was  due  to  an  inability  to  speak  for  a number  of  different 
users  within  the  organization.  Exhibit  IV-5  lists  the  responses  obtained. 

• Typical  files  are  generally  small;  it  was  rare  to  hear  of  a typical 
file  size  of  over  one  million  characters. 

• Maximum  file  sizes  ranged  from  only  350K  to  100  million  characters. 

In  general,  the  largest  file  sizes  reported  would  be  easily  managed  on  anv 
remote  batch  system. 

• As  expected,  business  users'  file  requirements  far  exceeded  those  of 
the  scientific  users.  The  government  users  surveyed  reported  larger  files 
than  either  the  business  or  scientific  users  in  the  commercial  sector. 
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EXHIBIT  IV- 5 


REMOTE  BATCH  USERS'  FILE  SIZES  - (CHARACTERS) 


User  Type 

Typical 

Maximum 

Business 

Small 

Small 

2 MM 

Small 

25  MM 

240  K 

— 

1 MM 

2 MM 

2 MM 

90  MM 

— 

60  MM  (total) 

— 

100  MM  (total) 

15  MM 

100  MM  (total) 

Scientific  & 

Small 

___ 

Engineering 

Small 

— 

Small 

1 MM 

72  K 

350  K 

100  K 

— 

130  K 

— 

130  K 

650  K 

300  K 

2 MM 

Combined  Business 

Small 

4 MM 

& Scientific 

600  K 

5 MM 

6 MM 

Federal 

1 MM 

15  MM 

Government 

2 MM 

— 

2 MM 

11  MM 

20  MM 

— 

40  MM 

100  MM 

K = Thousands 
MM  = Millions 
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3.  INPUT/OUTPUT  REQUIREMENTS  ARE  NOT  CLEAR 


• At  one  time  or  another,  many  users  surveyed  use  vendor  provided 
facilities  for  output.  Typically,  bulk  printing  is  done  either  at  the 
remote  computer  center  or  at  a medium-high  speed  printer  in  the  local 
sales  office. 

• Less  frequent  was  the  use  of  vendor  provided  facilities  for  input. 
Two  users  had  no  terminals  of  their  own  and  used  local  office  terminals 
exclusively.  Tape  input  was  rarely  encountered  and  in  those  cases  the 
mail  was  used  to  deliver  the  tapes  to  the  remote  computer  center. 

• Input/output  volumes  are  not  clear  to  us  as  the  users  found  such 
questions  difficult  to  answer.  The  few  intelligible  responses  indicated 
relatively  low  volumes  routinely  and  occasionally  higher  volume  output 
which  was  done  either  on  their  terminal  equipment  or  at  the  vendor's 
site.  Exhibit  IV-10,  illustrating  current  and  future  terminal  speeds, 
may  give  an  indirect  indication  of  the  input/output  volumes  associated 
with  remote  batch  usage. 

4.  TURNAROUND  REQUIREMENTS  ARE  DEMANDING 

Exhibit  IV- 6 illustrates  the  turnaround  requirements  - in  terms  of 
the  percentage  of  jobs  - as  expressed  by  the  users  surveyed.  The  less 
than  one-half  hour  category  was  added  after  the  mid-point  of  the  study 
and,  hence,  the  sample  is  smaller  than  for  the  other  data.  The  figure 
was  derived  by  computing  the  < 1/2  hour/1/2—2  hour  ratio  for  those  users 
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EXHIBIT  IV- 6 


TURNAROUND  REQUIREMENTS  FOR  REMOTE  BATCH  JOBS 


Less  than 
1/2  hour 


1/2-2  hours 


2 - Q hours 
(sane  day) 


Next  day 


% of  Jobs 
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who  were  asked  and  applying  the  result  to  the  less  than  two  hour  percentage 
given  by  those  who  were  not  asked  for  a less  than  one-half  hour  percentage. 

• Over  40%  of  the  jobs  require  turnaround  of  two  hours  or  less;  one  job 
in  six  requires  turnaround  of  less  than  one-half  hour. 

• About  40%  of  the  jobs  are  not  required  to  be  processed  the  same  day 
and  overnight  processing  is  deemed  adequate.  The  balance  of  20%  is  re- 
quired the  same  day  but  there  is  no  need  for  great  haste. 

• Under  subsequent  questioning,  users  indicated  that  poor  turnaround 
was  one  of  the  major  reasons  why  they  would  consider  switching  vendors 
of  remote  batch  services.  However,  the  turnaround  requirements  as 
reported  by  the  users  are  generally  being  met  by  remote  batch  vendors  at 
this  time. 

• Scientific  users  demanded  two-thirds  of  their  jobs  run  in  less  than 
two  hours;  business  users  demanded  one- third  of  their  jobs  run  in  less 
than  two  hours. 

• Scientific  users  could  wait  until  the  next  day  for  almost  all  jobs 
that  were  not  demanded  in  less  than  two  hours  and  expressed  very  little 
"same  day"  demand.  About  one  quarter  of  the  business  jobs  could  be 
satisfied  by  "same  day"  processing  while  close  to  half  could  be  run 
overnight. 

• Government  users  surveyed  on  the  question  of  turnaround  answered 

very  much  like  the  scientific  users:  About  taro-thirds  of  their  jobs 
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require  less  than  two  hours  turnaround;  there  is  very  little  "same  day" 
demand;  the  balance  of  about  one— third  is  satisfied  by  overnight  processing. 

5.  EXECUTION  TIME  RANGES  UP  TO  HOURS 

Exhibit  IV-7  depicts  the  distribution  of  execution  time  required  by 
typical  and  maximum  runs.  It  was  not  possible  to  correlate  the  execution 
time  responses  to  particular  mainframe  types  and  thereby  derive  some  sort 
of  standard  by  which  to  measure  the  times.  The  reader  is  directed  to 
Exhibit  IV- 1,  which  lists  the  mainframes  in  use  by  the  respondents,  to  get 
a feel  for  the  size  of  these  jobs.  In  general,  the  systems  in  use  are  the 
largest  available  and  these  times  should  be  viewed  as  "very  large  minutes". 

• Three  out  of  four  typical  jobs  require  execution  time  of  less  than 
ten  minutes;  most  of  the  balance  require  less  than  one-half  hour  of 
execution  time. 

• Maximum  jobs  are  quite  large  with  about  40%  of  the  largest  runs 
requiring  in  excess  of  one  hour  of  computing.  Half  of  the  maximum  jobs 
required  from  five  to  sixty  minutes  of  processing  and  the  balance  of  about 
10%  of  the  jobs  required  less  than  five  minutes  of  execution  time. 

• The  longest  run  times  were  not  exclusively  generated  by  scientific 
users.  Many  of  the  business  users  ran  models  of  one  sort  or  another  that 
also  required  large  amounts  of  processing.  Uhile  to  the  computer  system 
these  may  look  like  scientific  programs,  the  applications  and  the  users 
are  business  oriented. 
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EXHIBIT  IV- 7 


REMOTE  BATCH  JOB  EXECUTION  TIME  - TYPICAL  RUN 


< 1 minute 

20% 

- 10  minutes 

56% 

- 30  minutes 

20% 

> 30  minutes 

4% 

j i 

20  40  60 

% of  Users 


EXECUTION  TIME  - MAXIMUM  RUN 


< 5 minutes 

9% 

- 30  minutes 

32% 

- 60  minutes 

18% 

1-3  hours 

23% 

> 3 hours 

18% 

1 

i 

i 

10  20  30  40 

% of  Users 
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6. 


JOBS  ARE  RUN  FREQUENTLY 


Exhibit  IV— 8 displays  the  frequency  with  which  the  remote  batch 
users  surveyed  executed  jobs.  No  attempt  was  made  to  determine  the 
actual  number  of  jobs  submitted  over  time;  this  is  merely  an  indication 
of  the  frequency  of  their  use  of  a remote  batch  service. 

• More  than  half  of  the  users  run  jobs  on  a daily  basis;  many  of 
these  run  jobs  a number  of  times  within  a day. 

• Another  one  quarter  of  the  users  run  jobs  weekly  resulting  in  a 
total  of  about  80%  of  the  users  being  quite  regular  in  their  use  of 
services.  This  is  consistent  with  the  use  of  remote  batch  for  production 
type  work. 

• The  remainder  - or  about  one  user  in  five  - only  execute  programs  on 
a monthly  basis  or  even  less  frequently.  Their  use  tends  to  be  project 
oriented  and  comes  and  goes  with  the  nature  of  their  business  mix. 

• There  was  no  discernible  difference  between  business  and  scientific 
users  on  the  question  of  frequency  of  execution. 

7.  MAJOR  LANGUAGES  ARE  ALL  IN  USE 

• Exhibit  IV- 9 indicates  the  frequency  with  which  users  gave  various 
responses  when  asked  what  languages  they  were  using.  A number  of  users 
gave  multiple  responses  which  indicates  the  variety  of  applications  being 
run  on  remote  batch  by  single  companies. 
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EXHIBIT  IV- 8 


FREQUENCY  OF  REMOTE  BATCH  JOB  EXECUTION 


Daily 


Weekly 


Monthly 


Less  than 
monthly 


Average  Percentage  of  Users'  Expenses 
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EXHIBIT  IV- 9 


LANGUAGE  USED  BY  USERS 
OF  R/B  SERVICES 


Language 

Frequency 

Fortran 

14 

COBOL 

11 

Assembler 

6 

PL/ 1 

6 

Other 

3* 

* (RPG  - 2) 
(GPSS  - 1) 

Number  of  Respondents 
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• No  language  stood  out  as  being  dominant  over  the  others;  no  major 
language  stood  out  by  being  absent  from  the  list.  Remote  batch  users 
will  require  that  all  major  languages  be  supported. 
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E. 


DATA  COMMUNICATIONS 


1.  TERMINAL  SPEEDS  INCREASING  MODESTLY 

• Exhibit  IV-10  illustrates  the  trend  toward  higher  speed  terminals 
which  will  be  in  use  by  users  of  remote  batch  services. 

• In  general,  the  low  speed  users  will  migrate  to  6-1200  BPS  and  the 
medium  speed  users  will  tend  to  go  up  one  notch  faster  than  they  are  at 
present.  Only  one  user  of  more  than  9600  BPS  (50  KB)  was  discovered. 

• No  users  expressed  that  their  use  of  remote  batch  was  significantly 
hampered  by  terminal  speeds  or  output  capacities.  In  addition,  the 
increased  speeds  planned  would  adequately  cover  future  volumes  and 
convenience  considerations. 

• Some  users  will  continue  to  rely  upon  vendor  provided  facilities 
for  all  of  their  terminal  and  data  communications  needs. 

• Virtually  all  medium  speed  terminals  reported  were  of  the  2780 

compatible  type.  Only  two  small  computers  were  uncovered  being  used  as 
terminals:  an  HP-2100  by  a scientific  user  and  a System/3  by  a business 

user.  In  both  cases  the  small  systems  were  also  used  for  some  local 
processing. 

• Ten  users  reported  submitting  jobs  from  low  speed  terminals.  Some 
of  these  users  had  no  medium  speed  capability  and  relied  on  vendor 
facilities  for  all  bulk  output. 
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Line  Speed  in  Baud 


EXHIBIT  IV- 10 


COMMUNICATION  SPEED  IN  USE  - CURRENT/FUTURE 


0 - 300 


600  - 1200 


2000  - 2400 


4800 


7200 


9600 


> 9600 


Vendor 

facility 


Number  of  Responses 
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2. 


TECHNICAL  REQUIREMENTS  OF  NETWORKS  ARE  EASY  TO  MEET 


• No  user  was  encountered  with  a need  for  a highly  sophisticated  data 
communications  network.  Virtually  all  of  the  users  surveyed  would  be 
satisfied  with  a star  network  composed  of  leased  lines  and  perhaps 
complemented  with  WATS. 

• Slightly  less  than  one-third  of  the  users  expressed  any  need  for  a 
multi-city  network  at  all.  In  two-thirds  of  the  cases  they  were  only 
concerned  with  reasonable  access  from  one  location.  Exhibit  IV-11  depicts 
this  lack  of  a need  for  a network  by  most  users. 

• Exhibit  IV-11  also  illustrates  the  incidence  of  various  means  of 
accessing  the  main  computer  systems.  (The  figures  add  to  over  100% 
because  of  multiple  systems  use  by  some  of  the  users.)  Only  one  user 
accessed  the  services  vendor  by  long  distance  dial  exclusively;  all 
other  users  make  connection  via  local  dial  and/or  leased  line. 

• When  a leased  line  is  installed  for  a particular  user  it  is  common 
for  the  remote  batch  vendor  to  install  and  maintain  the  service  and  pass 
the  cost  of  the  circuit  along  to  the  user  as  a separate  item  on  the 
computer  services  invoice. 

• Users  were  only  informally  queried  on  their  future  use  of  networks 
and  all  that  can  be  said  is  that  they  do  anticipate  some  increased  need 
for  such  a capability.  In  addition,  it  appears  that  some  non-users  can 
be  induced  to  use  remote  batch  services  in  conjunction  with  a network 
capability. 
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EXHIBIT  IV-11 


USER  REQUIREMENTS  FOR  MULTI-CITY  NETWORK 


Yes 

32% 

No 

68% 

I 

1 

1 

25 

1 

50 

1 

75 

% of  Users 


CURRENT  ACCESS  TO  R/B  SYSTEM 


Local  dial 


Long  distance 
dial 


Leased  line 


NOTE:  Adds  to  over  100%  because  of  multiple  systems  use  by  many  users. 
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MARKETING  REQUIREMENTS 


INPUT 


i 


V. 


MARKETING  REQUIREMENTS 


A.  WHY  USERS  USE  REMOTE  BATCH  SERVICES 

1.  USERS  WITH  IN-HOUSE  SYSTEMS  ARE  BUYING  SPECIAL  HARDWARE  OR  SOFTWARE 

Users  of  remote  batch  services  with  medium  to  large  scale  in-house 
computer  systems  were  asked  why  they  used  outside  remote  batch  services; 
Exhibit  V-l  depicts  their  responses.  In  some  cases  multiple  responses 
were  given  by  individual  users. 

• Special  hardware  capability  was  the  most  frequently  given  reason 
by  this  group  of  users  for  the  use  of  outside  services.  More  specifically, 
they  indicated  their  need  for: 

- Larger  word  size  necessitated  by  some  applications  such  as 
nuclear  code  work 

- Larger  memory  than  presently  available  on  the  in-house  systems 
Greater  CPU  power,  which  was  generally  required  for  scientific 
applications,  but  some  business  users  had  large  models 
requiring  more  processing  than  could  be  handled  by  present 
in-house  systems 
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EXHIBIT  V-l 


WHY  USERS  WITH  MEDIUM- LARGE 
IN-HOUSE  SYSTEMS  USE  R/B  SERVICES 


Hardware 

capability 


Vendor  provided 
application  software 


Network 


Turnaround 


Economics 


Number  of  Responses 
(Total  = 31) 
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• Vendor  provided  application  software  was  the  second  most  common 
reason  given  by  these  users  for  the  use  of  remote  batch  services.  This 
cause  was  ranked  close  to  special  hardware  requirements  and  each  of 
these  factors  were  far  more  common  than  any  other  reason. 

- In  some  cases  this  software  was  not  strictly  proprietary 
but,  rather,  in  the  public  domain.  The  vendors  had  modified 
these  programs  to  run  on  their  systems  and  sometimes  made 
functional  improvements. 

- Some  users  commented  that  the  conversion  costs  involved  in 
order  to  make  these  programs  run  in-house  were  prohibitive. 

If  it  were  not  for  that  cost  they  would  run  the  jobs  on  their 
in-house  systems. 

- The  balance  of  the  cases  were  true  proprietary  application 
systems  developed  by  the  vendors  for  specific  markets. 

These  cases  were,  however,  in  the  minority. 

• Network  availability  was  given  significantly  fewer  mentions 
although  it  is  a key  factor  for  some  current  users  with  in-house 
capability.  These  users  were  typified  by  geographically  dispersed 
operations  centers  with  a need  for  common  programs  and/or  data  base. 

• Turnaround  was  also  mentioned  - although  infrequently  - as  a reason 
to  go  outside.  In  these  cases  the  in-house  systems  could  not  satisfy 
all  using  departments'  turnaround  requirements  or  justify  the  additional 
facilities  required  to  satisfy  the  most  demanding  users. 
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• Economics  was  only  mentioned  once  as  a reason  to  use  outside 
services  by  those  users  having  significant  in-house  capability.  While 
it  is  true  that  all  of  the  above  mentioned  reasons  can  be  considered 
economic  in  nature,  it  is  interesting  to  note  that  they  are  not  discussed 
in  economic  terms  by  the  users.  The  thought  process  of  these  users  is  to 
do  their  work  in-house  unless  they  are  prohibited  by  economics;  users  with 
no  in-house  systems  or  small  in-house  systems  look  for  the  most  economic 
solution  first  and  do  not  display  the  bias  for  in-house.  (See  the 
following. ) 

2.  USERS  WITHOUT  IN-HOUSE  SYSTEMS  ARE  BUYING  ECONOMICAL  SOLUTIONS 

Users  of  remote  batch  services  who  did  not  have  in-house  systems  or 
who  only  had  small  in-house  systems  were  also  asked  why  they  used  outside 
remote  batch  services.  Exhibit  V-2  depicts  their  responses  to  this 
question. 

• Economic  considerations  were  by  far  the  major  reason  given  for  the 
use  of  services.  This  is  in  sharp  contrast  to  the  users  with  larger 
in-house  systems  who  consider  economics  a secondary  issue.  In  essence 
they  feel  that  the  most  cost  effective  way  for  them  to  meet  their  data 
processing  needs  is  to  use  a small  part  of  a large  machine.  Users  with 
small  in-house  systems  often  used  them  in  a fashion  which  was  complementary 
to  the  remote  batch  service. 

• Unique  hardware  capability  was  mentioned  by  scientific  users  who 
expressed  their  familiar,  unique  requirements. 
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EXHIBIT  V-2 


WHY  USERS  WITH  SMALL  OR 
NO  IN-HOUSE  SYSTEM  USE  R/B  SERVICES 


Hardware 

capability 


Vendor  provided 
application  software 
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Number  of  Responses 
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• Vendor  provided  applications  currently  play  a minor  role  for  these 
users.  More  typically  the  vendor  is  being  used  as  a "computer  utility". 

• Only  one  user  with  little  in-house  capability  mentioned  a network 

as  reason  for  the  use  of  outside  services.  These  smaller  data  processing 
users  tend  to  be  smaller  organizations  and,  therefore,  tend  not  to  have 
the  multiple  locations. 

3.  "GROWTH"  THE  MAJOR  FACTOR  LEADING  TO  INCREASED  USE 

Current  users  were  asked  what  developments  might  lead  to  increased 
use  of  remote  batch  services;  their  responses  are  presented  in  Exhibit  V-3. 
The  following  three  causes  were  given  in  remarkably  even  proportions: 

• Normal,  expected  growth  of  their  present  business  and  applications 
was  considered  to  be  a cause  for  increased  use.  Either  programs  would  be 
run  more  frequently  or  file  sizes  would  expand  causing  a corresponding 
increase  in  processing  charges. 

• An  equal  number  of  users  foresaw  new  applications  relating  to  their 
present  business  as  a source  for  increased  use  of  services. 

• Almost  as  many  users  felt  that  new  business  activity  would  generate 
additional  remote  batch  usage.  Included  in  this  area  were  new  areas  of 
business  as  opposed  to  additional  work  in  their  present  areas. 
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EXHIBIT  V-3 


FACTORS  CAUSING  AN  INCREASE 
OR  DECREASE  IN  USE  OF  R/B  SERVICES 


Increase  Factors 

Number  of 
Responses 

o Growth  of  existing  business  and 

6 

applications 

o New  applications  related  to  existing 

6 

business 

o New  business 

5 

Decrease  Factors 

c Conversion  to  in-house 

11 

© Use  of  minis  to  reduce  (not  displace)  R/B 

2 

o Decline  in  related  business  activity 

2 

NOTE:  Eight  users  had  current  plans  to  reduce  usage  of 

R/B  services. 
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4. 


CONVERSION  TO  IN-HOUSE  IS  MAJOR  CAUSE  OF  DECREASED  USE 


Current  users  of  remote  batch  services  were  also  asked  what  develop- 
ments would  lead  to  a decreased  use  of  services.  Exhibit  V-3  presents 
their  responses.  Three  reasons  were  given  for  decreased  usage: 

• By  far  the  most  commonly  mentioned  development  which  would  lead  to 
decreased  usage  of  remote  batch  services  was  a conversion  to  in-house 
processing.  Eight  of  the  eleven  users  responding  in  this  fashion  had 
current  plans  to  bring  some  or  all  of  their  remote  batch  usage  in-house 
within  one  year.  Additional  computer  systems,  computer  upgrades,  and 
operating  system  enhancements  were  all  mentioned  as  the  vehicles  for 
this  conversion. 

• Also  mentioned  was  the  use  of  minis  which  would  result  in  some 
decreased  usage.  These  devices  would  be  used  in  conjunction  with  present 
services  and  were  not  intended  to  displace  the  services;  some  amount  of 
local  processing  or  data  collection  would  be  done  by  the  minis  and  the 
balance  of  the  work  would  be  done  on  the  service  computer.  (Note  that 
this  is  actually  a permutation  of  the  in-house  conversion  situation.) 

• A small  number  of  users  foresaw  a potential  decrease  in  their 
business  activity  which  related  to  remote  batch  usage.  As  a direct 
consequence  their  use  of  services  would  also  decline. 
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WHY  NON-USERS  DO  NOT,  BUT  MIGHT,  USE  REMOTE  BATCH  SERVICES 


Non-users  of  remote  batch  services  were  surveyed  to  determine  why 
they  are  not  using  such  services  and  under  what  conditions  they  might. 
These  non-users  consisted  of  companies  which  use  no  outside  services 
and  companies  which  use  outside  time  sharing  but  no  outside  remote  batch. 
In  all  cases  the  companies  surveyed  were  Fortune  500  or  equivalent  com- 
panies and  all  had  substantial  in-house  capability.  The  consistency  of 
their  responses  led  us  to  drop  further  study  at  the  mid-point  of  the 
study. 

1.  IN-HOUSE  CAPABILITY  ELIMINATES  NEED  FOR  OUTSIDE  REMOTE  BATCH 

• Invariably  the  reason  for  not  using  remote  batch  services  was  the 
current  availability  of  a competitive  in-house  capability. 

• No  significant  difference  in  responses  was  determined  between  the 
non-service  users  and  those  who  used  time  sharing. 

• Exhibit  V-4  is  a collection  of  colorful  comments  from  non-users 
which  will  give  the  reader  a feeling  for  the  situation. 

2.  PROPRIETARY  SOFTWARE  IS  LEADING  REASON  WHY  NON-USERS  MIGHT  USE 

• Exhibit  V-5  lists  the  reasons  given  by  non-users  of  remote  batch 
services  for  potential  future  use.  Software  and  hardware  capabilities 
were  the  major  reasons  given. 
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EXHIBIT  V-4 


WHY  NON-USERS  DO  NOT  USE  R/B  SERVICES 


Comments  from  Non-Users 


"Rates  attractive  enough  for  emergency  need  but  not  for 
regular  use" 


"Experience  is  that  in-house  is  a fraction  of  the  cost 
of  out-house" 


"Difficulty  of  getting  reliable  and  firm  cost  estimates 
for  budgeting  results  in  reduced  use  of  services" 


"Have  not  yet  had  a need  we  could  not  fill  with  in-house 
capability" 


"Only  if  our  backs  are  to  the  wall" 


"Jobs  brought  in-house  (TSO/155)  cost  1/4  to  1/2  of  outside 
services" 


"Hard  to  get  anything  done  outside;  operating  efficiency 
cut  about  50%" 
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EXHIBIT  V-5 


WHY  NON-USERS  MIGHT  USE  R/B  SERVICES 


Reason  Given 

Frequency 

% of  Non-Users* 

Proprietary  Application  Software 

7 

58% 

Overflow  Processing 

5 

42% 

Proven  More  Economical 

2 

17% 

Use  of  Network 

1 

8% 

* NOTE:  Exceeds  100%  because  of  multiple  responses  by  users. 
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• Proprietary  application  software  availability  was  the  prime  reason 
foreseen  for  potential  use.  If  the  development/conversion  cost  exceeds 
the  remote  computer  service  charges,  they  will  use  the  service.  However, 
if  they  can  see  a way  to  do  it  in-house,  they  probably  will. 

• An  overload  situation  on  the  in— house  systems  was  also  seen  as  a 
common  potential  need  for  remote  batch  services.  This  need  would  be 
eliminated  as  soon  as  the  in-house  systems  could  be  expanded  to  handle 
the  load.  A useful  analogy  might  be  the  way  one  would  perceive  a bald 
spare  tire. 

• A small  number  of  non-users  stated  that  they  would  use  remote  batch 
services  if  it  could  be  proven  to  be  more  economical.  No  judgment  can 

be  made  from  the  data  as  to  how  many  of  these  non-users  would  "play  fair" 
in  the  cost  comparisons  necessary  to  resolve  this  issue. 

• One  non-user  stated  that  a potential  future  need  for  a network 
capability  could  result  in  the  use  of  remote  batch  services. 
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c. 


VENDOR  SELECTION  CRITERIA 


1.  HARDWARE  AND  PRICE  CONSIDERED  MOST  IMPORTANT 

Exhibit  V-6  illustrates  the  relative  importance  users  placed  upon 
a variety  of  factors  evaluated  in  the  process  of  selecting  a vendor  of 
remote  batch  services.  Surprisingly,  the  responses  for  each  factor 
ranged  from  one  to  ten;  the  average  value  is  presented  in  the  Exhibit. 
Where  government  users  varied  significantly  from  the  commercial  users, 
the  appropriate  comment  is  made. 

• User  Proximity  to  Vendor  Hardware:  While  logically  it  might  seem 

to  be  a virtually  irrelevant  issue,  many  users  continue  to  express  a 
preference  for  proximity  to  the  vendor's  hardware.  20%  of  the  respondents 
rated  this  an  eight  or  higher  in  importance  to  them.  The  average  value 

is  low,  however,  because  almost  half  of  the  respondents  rated  this  factor 
at  two  or  less.  In  some  cases  the  availability  of  a nearby  line  printer/ 
card  reader  will  satisfy  the  users  demanding  proximity.  Government  users 
rated  this  factor  more  important  than  did  the  commercial  users. 

• Availability  of  a Multi-City  Network:  The  average  may  be  somewhat 

misleading  since  the  respondents  tended  to  fall  at  one  end  of  the  scale 

or  the  other.  One-third  of  the  users  rated  it  eight  or  higher  while  about 
one-half  rated  it  two  or  lower.  One  in  three  remote  batch  users  presently 
require  a multi-city  network  for  their  applications  and  the  availability 
of  such  a network  will  increase  in  importance  in  the  future. 
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EXHIBIT  V-6 


REMOTE  RATCH  VENDOR  SELECTION  FACTORS 


User  proximity  to 
vendor  hardware 


Multi-city  network 


Vendor  provided 
applications 


Technical  support 
and  training 


Price 


Vendor  hardware 
and  operating  system 


Relative  Importance 
(1  = unimportant;  10  = critical) 


OTHER:  (Frequently  mentioned  as  being  very  important) 

RELIABILITY 

TURNAROUND 
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• Availability  of  Vendor  Provided  Application  Programs:  Once  again 

few  users  gave  the  average  response  to  this  factor.  About  40%  rated 
this  at  two  or  less  while  about  30%  rated  it  at  eight  or  more.  The 
availability  of  software  packages  was  frequently  mentioned  by  non-users 
as  a condition  under  which  they  might  use  remote  batch  services  in  the 
future. 

• The  Quantity  and  Quality  of  Technical  Support  and  Training:  The 

responses  here  were  more  evenly  distributed  and  such  support  was  consid- 
ered to  be  a relatively  important  factor.  Users  do  not  tend  to  require 
a lot  of  support  in  terms  of  hours  per  week  and,  therefore,  judge  the 
support  in  terms  of  how  quickly  they  can  get  their  questions  answered 
correctly. 

• Price:  Less  than  10%  of  the  users  rated  price  lower  than  five  in 

importance  to  them;  it  is  clearly  one  of  the  prime  factors  in  their 
analysis  of  a potential  vendor.  As  might  be  expected,  the  government 
users  rated  this  factor  as  more  important  to  them  than  it  was  to  the 
commercial  users.  In  addition  to  its  importance  in  selecting  which 
service  vendor  to  use,  price  is  also  key  in  the  decision  to  use 
services  as  opposed  to  an  in-house  solution  and,  therefore,  low  prices 
will  be  key  to  overall  market  development. 

• Particular  Vendor  Hardware  and  Operating  Systems:  Current  users 

rated  this  the  most  important  factor  in  their  selection  of  a remote 
batch  vendor  for  a variety  of  reasons:  the  cost  of  converting  present 

programs,  the  availability  of  programs  for  certain  systems  only  (e.g., 
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nuclear  code  programs  written  for  CDC  equipment),  and  a desire  for 
compatibility  with  in-house  systems.  The  strong  attachment  was  to 
mainframe  type  with  particular  operating  system  playing  a relatively 
minor  role.  Obviously,  business  users  were  partial  to  IBM  while 
scientific  users  were  partial  to  CDC  and  Univac. 

• Other  Factors:  When  asked  if  other  factors  were  important  in 

their  selection  process  many  users  volunteered  reliability  and  slightly 
fewer  mentioned  turnaround.  When  asked  to  rank  reliability,  they  almost 
invariably  replied  with  eight  or  greater.  Also  mentioned  were  security, 
financial  stability,  billing  flexibility,  and  ease  of  use. 

2.  USERS  WOULD  SWITCH  VENDORS  IF  "SERVICE"  DETERIORATED 

The  conditions  - other  than  price  - under  which  users  would  switch 
vendors  were  explored  in  the  course  of  this  study.  (For  a discussion  of 
price  sensitivity,  see  the  following  section.)  In  general,  a deterioration 
in  existing  "service"  levels  would  be  required  to  cause  a switch  in  the 
absence  of  price  considerations;  users  are  generally  satisfied  at  this 
time.  Exhibit  V-7  illustrates  the  relative  importance  of  the  various 
"service"  components. 

• Reliability  was  discussed  in  terms  of  both  computer  system  and  net- 
work failures.  Much  of  the  use  of  these  services  are  production  in 
nature  and  cannot  stand  processing  failures  of  any  kind. 

• Poor  turnaround  was  the  next  most  frequently  reported  condition 
which  could  result  in  a vendor  switch.  Users  complained  of  poor  turn- 
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EXHIBIT  V-7 


WHY  CURRENT  USERS  WOULD  SWITCH  VENDORS 


Availability  of 
improved  application 
software 


Poor  user 
support* 


Poor 

turnaround* 


Poor 

reliability* 


Non-specific 
"poor  performance" 
or  "better  service"* 


Number  of  Responses 
(Total  = 36) 


* NOTE:  Users  spoke  of  a hypothetical  worsening;  of  service; 

present  conditions  are  generally  satisfactory. 
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around  conditions  being  allowed  to  persist  too  long  before  additional 
hardware  was  brough  in  by  the  vendors. 

• Unsatisfactory  user  support  or  problem  solving  was  somewhat  less 
frequently  mentioned  as  a switch  condition.  As  shown  in  a later 
section,  these  users  are  fairly  self-sufficient  and  do  not  require  a lot 
of  technical  support  so  their  demand  for  it  is  lower  than  their  demand 
for  system  performance. 

• Non-specific  conditions  of  "poor  performance"  or  "better  service" 
also  ranked  high  and  are  presented  separately  because  it  is  not  known 
into  which  of  the  three  above  categories  they  should  be  sorted. 

• "Service"  to  these  users  means  reliability,  turnaround  and  user 
support. 

• The  only  condition  under  which  users  would  switch  which  was  not 
related  to  service  was  the  potential  availability  of  improved  application 
software.  These  users  would  switch  if  the  package  were  functionally 
superior  to  the  one  presently  in  use. 
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D. 


PRICING 


1.  USERS  SENSITIVE  TO  MODERATE  PRICE  DIFFERENCES 

Exhibit  V-8  illustrates  the  difference  in  price  which  would  be 
required  by  a user  to  switch  to  another  vendor  offering  an  otherwise 
similar  service. 

• The  average  price  difference  which  would  cause  a switch  in  vendors 
was  23%. 

• Many  users  objected  to  our  attempt  to  isolate  price  from  other 
considerations  but  only  14%  replied  that  it  was  not  a significant  factor 
and  that  they  would  not  switch  for  price  alone. 

• More  than  half  (54%)  would  switch  vendors  for  a price  difference 
of  20%  or  less. 

2.  TERMS  AND  CONDITIONS  ARE  VARIABLE 

• Most  users  have  short  term  contracts  which  obligate  them  to  little 
other  than  to  pay  for  services  used.  The  term  is  nominal,  the  prices 
are  standard,  and  the  services  offered  are  the  ones  normally  provided. 

• About  20%  of  the  users  had  signed  longer  term  contracts  which  often 
obligated  them  to  use  a specified  amount  of  service  over  the  life  of  the 
contract.  The  long  term  feature  was  the  most  common  variable  encountered 
and  often,  but  not  always,  involved  a reciprocal  discount. 
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Price  Difference  Required 


EXHIBIT  V-8 


PRICE  SENSITIVITY 


Price  not 
a factor 


40%  less 


30%  less 


20%  less 


10%  less 


Same  price 


4% 


14% 


11% 


21% 


14% 


(AVERAGE  = 23%) 


36% 


i ! 1 1 1 h 


H *- 


10  15  20  25  30  35  40  45  50 


% Users  Who  Will  Switch 
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• Quantity  discounts  existed  as  characteristics  of  standard  price 
schedules  and  also  as  part  of  special  contracts  involving  large  scale 
usage  and  long  term  commitment.  Contracts  of  this  nature  were  encount- 
ered with  about  15%  of  the  users  surveyed. 

• A number  of  interesting  special  arrangements  were  uncovered  of  a 
type  which  may  be  innumerable  in  variety: 

A free  2780-like  terminal  for  each  $5, 000/month  of  usage, 

- A change  in  the  billing  algorithm  to  reduce  the  importance 
of  core  utilization  for  a particular  user. 

Super-discounted  time  for  promotional  use  (such  as  preparation 
of  proposals  by  the  customer  which,  if  accepted,  would  result 
in  computer  services  business  for  the  vendor),  and 

- An  agreement  with  a particular  user  to  move  jobs  up  in  the 
queue  to  insure  processing  by  the  end  of  the  day  submitted. 

3.  PRICING  METHOD  PREFERENCES  ARE  MUNDANE 

A lack  of  enlightening  responses  to  questions  in  this  area  caused 
us  to  drop  further  research  at  the  mid-point  of  the  study.  There  were 
some  definite  trends,  however: 

• Users  are  familiar  with  and  favorable  toward  quantity  discounts  and 
do  not  expect  to  have  to  make  a long  term  commitment  to  get  them. 

• Long  term  contracts  are  only  attractive  when  there  is  some  certainty 
about  their  future  service  needs  and  volumes  and  the  users  will  normally 
expect  some  type  of  favorable  condition  in  return. 
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• The  basic  units  of  charge  are  in  terras  of  machine  resources  used 
(with  few  exceptions  which  are  application  oriented)  and  the  users  have 
no  objections  or  preferences  to  this  approach. 

• One  colorful  comment  was,  "I  have  tried  to  price  the  in-house  system 
and  am  familiar  with  the  problem  — whatever  is  fairl" 

4.  USERS  EXPECT  REMOTE  BATCH  TO  BE  ONE-HALF  THE  PRICE  OF  TIME  SHARING 

Exhibit  V-9  depicts  the  expected  price  difference  between  remote 
batch  services  and  time  sharing  services.  Many  users  commented  that  they 
would  never  use  time  sharing  if  remote  batch  could  do  the  job  and  one  user 
went  so  far  as  to  say  that  time  sharing  was  only  a state  of  mind!  Users 
do,  however,  have  clear  expectations  of  the  relative  costs: 

• Without  exception,  no  user  expects  to  pay  more  for  remote  batch 
than  they  would  pay  for  time  sharing.  Only  one  user  (3%  of  the  sample) 
thought  the  cost  would  be  about  the  same  for  their  applications. 

• Ninety-seven  percent  expect  to  pay  more  for  time  sharing  (less  for 
remote  batch)  for  a service  which  is  otherwise  similar.  (Note  that 
otherwise  similar  includes  turnaround  time.) 

• The  common  expectation  is  that  remote  batch  services  should  cost 
about  one-half  as  much  as  otherwise  similar  time  shared  services. 
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EXHIBIT  V-9 


EXPECTED  PRICE 


Less  for  T/S 


Same  for  T/S 


More  for  T/S 
(non-specific) 


< 2 times 
more  for  T/S 


2 times 
more  for  T/S 


3-5  times 
more  for  T/S 


DIFFERENTIAL  BETWEEN  TIMESHARING  AND  REMOTE  BATCH 


% of  Users 
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E. 


REMOTE  BATCH  SERVICES  DECISION  MAKERS 


• Exhibit  V-10  presents  by  title  or  function  who  in  the  companies 
surveyed  made  decisions  about  whether  or  not  to  use  remote  batch 
services  and,  if  so,  which  vendor  or  service  to  use. 

• In  the  non-using  companies,  it  was  almost  exclusively  the  chief  data 
processing  manager  who  made  the  decision. 

• Among  using  companies  the  chief  data  processing  manager  was  the  most 
frequently  mentioned  decision  maker,  making  the  final  decision  in  about 
one- third  of  the  cases.  However,  in  two- thirds  of  the  using  organizations, 
the  decision  maker  was  someone  other  than  the  D.  P.  manager. 

• The  end  user  verv  infrequently  was  empowered  to  authorize  expenditures 
for  computer  services.  Commonly,  however,  the  request  for  an  outside 
service  was  initiated  and  justified  by  the  ultimate  end  user  of  the 
service. 

• For  better  or  for  worse,  it  is  clear  that  when  the  D.  P.  manager 
does  not  control  the  decisions  regarding  services  vs.  in-house,  a wider 
variety  of  solutions  are  employed. 
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EXHIBIT  V-10 


R/B  SERVICES  DECISION  MAKERS 


Title  or 

Frequency 

Percent 

Function 

Users 

Non-Users 

Of  Users 

Of  Non-Users 

Chief  Data 
Processing  Manager 

11 

10 

36% 

84% 

Manager  or  Director 
of  Using  Department 
or  Division 

6 

1 

20% 

8% 

Committee 

4 

- 

13% 

- 

D.  P.  Analyst 

3 

- 

10% 

- 

Chief  Operating 
Officer 

2 

- 

6% 

- 

VP  Operations 

2 

- 

6% 

- 

Manager  General 
Services 

1 

- 

3% 

- 

Financial  Officer 

1 

1 

3% 

8% 

User 

1 

3% 

- 
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F. 


FIELD  PERSONNEL  REQUIREMENTS 


1.  TECHNICAL  SUPPORT  IS  AN  ISSUE  OF  QUALITY,  NOT  QUANTITY 

• As  shown  in  Exhibit  V-ll,  almost  two- thirds  of  the  users  stated 
that  they  required  one  hour  or  less  of  technical  support  per  week. 
Generally  this  is  in  the  nature  of  problem  solving  and  includes  questions 
relating  to  network  problems. 

• The  technical  support  required  tends  to  be  quick  answers  to  minor 
problems  which  are  holding  up  production.  Consequently,  users  are  looking 
for  ready  access  to  support  personnel  who  can  come  up  with  accurate  and 
complete  answers  in  a very  short  matter  of  time. 

• Exhibit  V-ll  also  illustrates  the  widely  held  belief  that  time 
sharing  requires  substantially  more  user  support  than  does  remote  batch. 
Users  estimated  that  time  sharing  required  from  25%  more  to  ten  times  as 
much  technical  support. 

• The  relatively  low  utilization  of  technical  support  by  remote  batch 
users  can  be  attributed  to  a number  of  factors: 

Generally  the  users  are  sophisticated  in  data  processing, 

— Much  of  the  work  is  production  in  nature  and  has  become  more 
or  Jess  routine,  and 

Remote  batch  operating  systems  seem  to  be  more  stable  than  time 
shared  operating  systems  and,  therefore,  generate  fewer  problems. 
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EXHIBIT  V-ll 


TECHNICAL  SUPPORT  REQUIRED 


BY  REliOTE  BATCH  USERS 


< 1 hour /week 


1 hour /week 


2 hours/week 
3-10  hours/week 


HOURS /WEEK 


% of  Users 


T/S  less 
T/S  same 
T/S  more 


REMOTE  BATCH  VS.  TIMESHARING 


Percentage  of  Respondents 
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2.  SALES  PERSONNEL  SHOULD  POSSESS  PRODUCT  KNOWLEDGE,  EMPATHY,  AND 
HONESTY 

With  relatively  few  exceptions,  the  users  surveyed  were  quick  to 
point  out  desirable  characteristics  of  salespeople  of  remote  batch 
services  (see  Exhibit  V-12).  While  some  users  commented  on  their 
satisfaction  with  their  present  salesperson,  and  some  talked  about 
used  cars,  most  merely  stated  what  they  would  like  to  see: 

® Product  Knowledge:  This  characteristic  was  mentioned  by  more  users 

than  any  other  and  was  generally  considered  to  be  in  short  supply. 
Technical  awareness  of  the  system's  capabilities,  ability  to  discuss 
available  applications,  and  knowledge  of  pricing  arrangements  were  all 
covered  by  their  comments.  While  the  users  do  not  expect  salespeople 
to  be  able  to  provide  technical  support,  they  do  expect  to  be  able  to 
discuss  functional  capabilities  of  the  various  service  offerings. 

• Ability  to  Understand  the  User’s  Situation;  The  next  most  commonly 
desired  characteristic  was  the  ability  to  understand  and  relate  to  the 
user's  environment  and  needs.  In  addition  to  the  product  knowledge 
required  for  this,  the  users  were  looking  for  the  salesperson  to  be  able 
to  take  the  user  perspective  and  to  have  enough  data  processing  experience 
to  be  able  to  comprehend  the  situation. 

• Honesty:  Equal  to  empathy  in  importance  to  the  users  was  honesty. 

This  heavenly  characteristic  was  also  discussed  in  terms  of  believability 
and  integrity.  In  essence,  the  users  demand  salespeople  who  do  not 
misrepresent  or  exaggerate  the  service  and  who  do  keep  their  word  on 
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EXHIBIT  V-12 


DESIRABLE  CHARACTERISTICS  OF  R/B  SALESPEOPLE 


Technical  knowledge 


Honesty/ integrity 


Ability  to  understand 
user  needs 


Ability/desire  to 
solve  problems 


Low-key  approach 


Patience 


Professionalism 


Humility 
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personal  promises.  Improved  product  knowledge  may  go  a long  way  in 
increasing  believability . 

• Ability  to  Solve  the  User's  Problems:  The  other  commonly  mentioned 

desirable  characteristic  was  the  salesperson's  willingness  and  ability  to 
quickly  solve  the  user's  problems.  Commonly  what  is  involved  is  the 
mustering  of  the  appropriate  company  resources  as  demanded  by  the 
particular  problem.  The  users  greatly  prefer  to  have  a single  contact 
who  can  get  to  an  answer  rather  than  to  have  to  call  around  the  service 
company  themselves. 

• Miscellaneous  Characteristics:  Also  mentioned,  in  order  of  frequency, 

were  a low  key  approach,  patience,  professionalism,  and  humility. 
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VI.  COMPETITIVE  ENVIRONMENT 


4 


4 
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VI  COMPETITIVE  ENVIRONMENT 


A.  VENDOR  GROUPS  AND  STRATEGIES 

1.  COMPUTER  MANUFACTURERS  WILL  EMPHASIZE  COMPUTER  ENHANCEMENT 

• IBM  does  not  obtain  US  revenues  from  remote  computing  services  and 
will  not  until  its  agreement  with  CDC  expires*  However,  at  about  1979/80 
IBM  will  introduce  a new  range  which  will  have  as  a component  the  provision 
of  computer  enhancement  through  a network.  This  will  provide  an  upgrade 
path  for  the  360/30  and  370/135  installations  in  particular. 

• The  IBM  impact  on  the  remote  batch  market  will  be  the  announcement 
this  year  of  a new  remote  computing  operating  system  which  will  have 
interactive  and  remote  batch  capabilities  to  replace  TSO,  HASP,  and 
VM/CMS.  It  will  be  based  on  the  Advanced  Function  for  Communications  and  be 
in  IBM's  mainstream  of  development.  Neither  TSO  nor  CMS  were  developed 

as  parts  of  IBM's  standard  operating  systems. 

This  software,  when  debugged,  will  enable  users  to  effectively  mix 
remote  batch  and  conversational  modes  on  the  same,  large-scale  computer. 

It  may  be  announced  with  the  awaited  370  Model  '178'. 

One  effect  of  this  will  be  to  create  more  competition  in  the  market 

- 105  - 


INPUT 


as  large  users  will  more  easily  be  able  to  offer  remote  services  than 
with  TSO,  for  example. 

• Honeywell  is  the  most  advanced  computer  manufacturer  in  terms  of  its 
movement  to  computer  enhancement.  DATANETWORK,  as  their  remote  computing 
service  is  called,  is  now  offered  in  conjunction  with  the  6000  series  for 
remote  data  entry,  remote  job  entry,  overflow,  and  backup.  Most  of  the 
revenues  at  this  point,  however,  are  interactive. 

Honeywell  is  making  a straight  play  for  the  large  GEIS  user  using 
DATANETWORK  as  an  interim  step  or  to  provide  features  which  the  in-house 
Honeywell  system  will  need,  such  as  the  network.  This  strategy  has 
succeeded  in  at  least  one  case  in  recent  months,  resulting  in  the  sale 
of  a large  computer. 

Honeywell  will  be  a powerful  competitor  in  the  computer  substitution 
part  of  the  remote  batch  market. 

• CDC  will  emphasize  its  business  problem  solving  capabilities  through 
both  SBC  and  CDC.  They  will  still  concentrate  at  the  high  end  of  the 
market  but  move  down  into  smaller  companies  as  they  develop  some  industry 
applications.  One  particular  target  industry  will  be  the  finance  and 
credit  industry  through  the  Commercial  Credit  system. 

The  CDC  emphasis  will  probably  be  by  industry  specialty.  SBC 
will  continue  to  push  the  selling  of  analytical  and  applications  tools  at 
the  strategic  level  in  client  organizations,  while  also  moving  towards 
industry  specialization.  SBC  will  emerge  as  the  dominant  organization 
with  CDC  services  group. 
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• NCR  will  concentrate  on  its  on-line  savings  and  mortgage  services, 

and  its  retail  store  services.  Major  tasks  are  to  convert  its  1+0  or  50  U.S. 
data  centers  onto  one  network  and  expand  its  capabilities  to  integrate 
the  banking  and  retailing  functions. 

NCR  will  be  a powerful  force  in  the  funds  transfer  area  when  that 
gets  off  the  ground.  However,  to  be  effective,  NCR  will  need  large-scale 
transaction  processing  and  teleprocessing  computers,  and  a sophisticated 
network.  The  situation  is  tailor-made  for  further  joint  NCR/CDC  efforts. 

• Sperry-Univac  does  not  appear  positioned  to  enter  the  remote 
computing  market.  One  area  that  it  is  interested  in  is  the  retail  indus- 
try through  support  of  POS  devices.  The  federal  government,  particularly 
DoD,  and  transportation  could  be  other  target  industry  sectors,  if  it 
decides  to  get  back  into  the  business. 

• Burroughs  has  the  computers  and  the  systems  software  to  be  very 
effective  in  the  remote  computing  market.  Its  marketing  emphasis  so  far 
has  been  geographically  and  industrially  limited  to  the  New  York  financial 
market. 

Burroughs  would  come  at  the  funds  transfer  business  from  the  other 
end  to  NCR,  i.e.  from  big  banks  as  opposed  to  small  thrift  and  retail 
organizations . 

• DEC  appears  to  have  no  plans  to  enter  the  market.  However,  its  recent 
network  software  announcements  shows  its* ability  to  service  the  market  with 
the  necessary  hardware  and  software.  It  probably  does  not  want  to  compete 
with  its  best  customers. 

- 107  - 


INPUT 


2 


INDEPENDENTS  DO  NOT  EMPHASIZE  REMOTE  BATCH 


• Computer  Sciences  Corporation  is  the  largest,  independent  computer 
services  company  in  the  remote  computing  market.  It  is  also  fairly  unique 
among  independents  in  having  a sizable  remote  batch  revenue  component  in 
its  INFONET  service. 

CSC  is  placing  a major  emphasis  on  the  growth  of  INFONET,  which  had 
a spectacular  increase  of  over  60#  in  revenues  from  197^  to  1975*  Indus- 
try emphasis  is  concentrated  on  the  major  industries  notably  the  federal 
government,  which  will  account  for  over  50#  of  1975  revenues,  banking, 
utilities,  and  manufacturing.  Of  the  federal  government  revenues,  over 
60#  are  for  remote  batch. 

• Optimum  Systems,  Inc.  will  have  over  10#  of  the  independents'  remote 
batch  revenues  in  1975 » running  third  behind  CSC  and  UCC.  OSI  is  the 
largest  independent  provider  of  IBM-based  remote  batch  services. 

At  least  half  of  its  remote  processing  revenues  come  from  large,  remote 
facilities  management  contracts  with  FEA  and  EPA.  Of  the  other  $10  million 
projected  in  remote  batch  revenues  in  1975,  half  come  from  industry  specia- 
lized services  and  the  remainder  from  'utility'  business,  including  com- 
puter substitution. 

• National  CSS  and  Tymshare  are  running  close  together  in  many  respects. 
Their  product  lines  are  similar:  both  basically  offer  interactive  pro- 
cessing with  deferred  run  capabilities.  Their  geographic  coverage  is 
similar  as  is  their  approach  to,  and  share  of,  the  market. 
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However,  they  are  different  in  several  fundamental  ways.  While  NCSS 
has  attempted  to  push  for  data  base  applications  and  problem  solving 
capabilities,  as  represented  by  RAMIS  and  the  professional  services  group, 
Tymshare  has  pushed  its  network  development  and  features.  Also,  NCSS  has 
made  heavy  use  of  its  IBM  capability,  while  Tymshare  has  only  recently 
added  a 370  to  its  inventory.  The  Tymshare  acquisition  of  UDC  will  give 
it  a growth  path  into  the  smaller  and  medium-sized  IBM  markets  which  will 
be  important  for  the  future  growth  of  the  industry. 

• UCC  is  the  largest,  independent  remote  batch  vendor  with  its  Univac 
1108  and  CDC  computers.  Its  main  emphasis  has  been  on  the  scientific 

and  engineering  market,  with  some  finance  industry  processing  in  New  York. 
It  will  broaden  this  base  into  the  business  processing  area,  possibly  in 
conjunction  with  the  banking  division. 

• Cyphernetics  is  one  of  the  fastest  growing  timesharing  companies. 

They  provide  superb  marketing  and  support  together  with  a very  efficient 
DEC  10  operation.  They  typically  target  in  on  GE  or  other  DEC  10  vendor 
customers.  They  appear  to  have  no  real  remote  batch  plans. 

• COMSHARE,  On-Line  Systems,  and  Rapidata  are  primarily  interactive, 
timesharing  vendors  with  deferred  run  capabilities.  Rapidata  has  already 
integrated  an  IBM  System  370  into  its  network:  this  has  been  a costly 
undertaking  for  them.  Also,  they  are  exposed  to  N.Y.  Telephone's  control 
over  a significant  part  of  their  revenues. 

Both  COMSHARE  and  On-Line  emphasize  problem  solution,  in  COMSHARE's 
case  primarily  for  big  users. 
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3.  SPINOFFS  ARE  THE  MAJOR  REMOTE  BATCH  MARKET  FACTORS 


• The  largest  spinoff,  GEIS,  is  in  fact  a very  small  recipient  of  remote 
batch  revenues.  It  does  perform  some  remote  batch  work  for  another  divi- 
sion of  GE.  GEIS*  main  thrust  has  been  geographic  coverage  including  the 
establishment  of  an  international  network.  Foreign  revenues  now  account 
for  approximately  one  third  of  GEIS*  revenues. 

• McAUTO  is  the  largest  vendor  of  remote  batch  services  through  its 
IBM  195  and  CDC  6000  series.  It  uses  Xerox  Sigma  computers  as  front  ends 
to  the  195s  for  interactive  processing  considerations. 

The  main  emphasis  for  McAUTO  has  been  large  structures  and  engineering 
applications.  Perhaps  its  most  significant  standard  product  revenue  gene- 
rator is  IMS:  a number  of  companies  use  McAUTO  to  get  an  IMS-based  system 

operational.  Hospital  services  are  mainly  interactive. 

• United  Computing  Systems  has  been  very  like  CDC  and  UCC  in  its  pro- 
vision of  scientific  and  engineering  services  to  utilities  (including 
'phone  companies,  of  course!),  large  aerospace  manufacturers,  engineering 
organizations,  and  oil  companies. 

• BCS,  Grumman,  and  Martin  Marietta  Data  Systems  are  heavily  into  the 
remote  batch  market,  although  Grumman  has  a larger  interactive  component 
than  the  others.  BCS  is  actively  looking  for  applications  specialized 
software  to  put  on  the  network,  particularly  in  the  financial  industries. 
MMDS  is  emphasizing  manufacturing  applications  processing  using  the  MAS 
software  obtained  from  Hoskyns.  Grumman  is  more  of  a 'computer  utility' 
concept. 
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• Xerox  Computer  Services  is  different  from  the  other  spinoffs  in  that 
it  was  established  to  operate  completely  independently  of  the  parent 
company's  data  processing.  It  covers  the  small  and  medium  sized  manufac- 
turer and  wholesaler  and  is  the  most  successful  venture  of  its  type.  Its 
remote  batch  component  is  very  low;  consisting  of  off-line  printing. 

• Two  spinoffs  also  operating  independently  from  the  parents'  EDP 
operations  are  the  GTE  and  Bunker  Ramo  stock  quotation  systems.  Neither 
of  these  has  significant  remote  batch  revenues.  However,  the  GTE 
organization  is  probably  up  for  sale  and  the  Bunker  Ramo  operation  is 
expanding  into  other  application  areas  involving  remote  batch  and  inter- 
active processing. 

H.  OTHER  VENDORS 

• The  Canadian  companies  moving  into  the  U.S.  remote  computing  market 

are  doing  so  mainly  in  the  remote  batch  area.  They  are  SDL,  Multiple  Access, 

I. P.  Sharp  (which  is  mainly  interactive),  and  Datacrown.  Of  these  SDL  and 
Multiple  Access  are  both  very  active:  Multiple  Access  has  acquired  TCC  and 
has  a foothold  in  the  insurance  industry. 

• Delos  from  France  has  purchased  ADR's  timesharing  operation  and  will 
expand  further.  This  is  the  first  European  company  to  attack  the  U.S. 
remote  computing  market. 

• Another  group  of  vendors  that  offer  competition  in  the  market  are 
those  companies  which  fairly  casually  sell  computing  services.  Some  of 
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these,  such  as  Fireman's  Fund,  will  move  into  the  category  of  fully 
fledged  spinoffs.  Others  will  continue  to  stay  local  in  scope.  Neverthe- 
less they  do  siphon  off  some  of  the  market.  As  IBM  upgrades  its  operating 
software  there  will  be  a major  increase  in  vendors  of  this  type. 

• A final  competitive  group  is  that  which  contains  universities, 
research  establishments  and  government  agencies.  Some  university  'spinoffs', 
such  as  Uni-Coil  from  Pennsylvania,  are  quite  aggresive  in  their  market 
approach  and  Uni-Coll  is,  in  fact,  a strong  competitor  in  the  Washington, 

D.C.  federal  government  market. 
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VENDOR  REVENUE  ANALYSIS 


1.  SPINOFFS  ARE  THE  LARGEST  REMOTE  BATCH  VENDOR  GROUP 

• Exhibit  VI-1  shows  the  vendor  groups  and  their  remote  batch  revenues 

in  1975 • If  GEIS,  GTE  Bunker  Ramo,  and  XCS  revenues  are  removed  from 
consideration,  remote  batch  services  revenues  to  spinoffs  are  greater 
than  their  interactive  and  data  bane  revenues  combined:  this  group  is 

different  from  most  spinoffs  in  that  they  were  not  established  as  an  out- 
growth of  the  in-house  processing  department. 

• By  far  the  largest  of  the  computer  manufacturers  in  U.S.  remote  com- 
puting revenues  is  CDC/SBC,  as  shown  in  Exhibit  VI  2.  Indeed,  it  is  now 
larger  than  any  other  company  in  this  market.  GEIS  is  slightly  larger,  at 
the  moment,  in  worldwide  revenues  due  to  its  position  overseas.  However, 
in  1976,  CDC  may  well  overtake  it  in  total  remote  computing  revenues. 

• The  computer  manufacturers,  with  the  exception  of  CDC  and,  possibly 
of  NCR,  regard  services  as  an  adjunct  to  equipment  sales  rather  than  as 

a stand-alone  market.  If  they  turn  around  on  this,  and  we  think  some  may, 
they  will  be  a powerful  market  force. 

• As  shown  in  Exhibit  VI-3,  the  emphasis  of  the  independent  vendors  is 
on  interactive  as  opposed  to  remote  batch  services.  The  area  in  which 
they  will  move  into  remote  batch  is  through  applications  specialized 
processing,  such  as  production  control  for  manufacturers. 

• There  are  an  increasing  number  of  spinoffs  entering  the  market.  These 
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EXHIBIT  VI-1 


U.S.  1975  REMOTE  COMPUTING  SERVICES  REVENUES 
BY  VENDOR  GROUP 


VENDOR  GROUP 

REMOTE 

BATCH 

INTERACTIVE 

DATA 

BASE 

TOTAL 

COMPUTER  MANUFACTURERS 

50 

100 

150 

INDEPENDENTS 

90 

1*10 

1*0 

5l*0 

SPINOFFS 

120 

170 

80 

370 

OTHERS 

20 

20 

1*0 

TOTAL 

280 

700 

120 

1,100 

($  MILLIONS) 


NOTE:  ONLY  ’AVAILABLE'  REVENUES  ARE  COUNTED:  SPINOFFS  REVENUES 

FROM  PARENTS  ARE  EXCLUDED. 
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EXHIBIT  VI-2 


COMPUTER  MANUFACTURERS'  1975  REMOTE  COMPUTING  SERVICES 
REVENUES  IN  THE  U.S. 


COMPANY 

REMOTE 

BATCH 

INTERACTIVE 

DATA 

BASE 

TOTAL 

IBM 

0 

HONEYWELL 

3 

5 

8 

UNIVAC 

2 

2 

BURROUGHS 

3 

3 

6 

NCR 

7 

15 

22 

CDC/SBC 

28 

75 

103 

SINGER 

7 

1 

8 

DEC 

0 

TOTAL 

50 

99 

0 

1U9 

($  MILLIONS) 
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EXHIBIT  VI-3 


INDEPENDENT  COMPUTER  SERVICES  COMPANIES’ 
1975  REMOTE  COMPUTING  REVENUES  IN  THE  U.S. 


COMPANY 

REMOTE 

BATCH 

INTERACTIVE 

DATA 

BASE 

TOTAL 

CSC 

17 

38 

55 

NCSS 

2* 

33 

35 

TYMSHARE 

1* 

31+ 

35 

UCC 

16 

1 

17 

CYPHERNETICS 

1* 

15 

2 

18 

COMSHARE 

1* 

14 

15 

R API DATA 

2 

16 

18 

ON-LINE 

12 

12 

OSI 

10 

10 

SUB-TOTAL 

50 

163 

2 

215 

OTHERS 

1+0 

21+7 

38 

325 

TOTAL 

90 

1+10 

1+0 

5l+0 

($  MILLIONS) 


* Deferred  run. 
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are  parts  of  large  companies  in  other  industries  which  are  chartered  to 
go  out  and  sell  computer  services  to  other  organizations.  Simply  selling 
surplus  time  does  not  qualify  as  a spinoff. 

In  particular  oil  companies  will  move  into  the  market,  from  1975 
onwards,  in  a manner  akin  to  the  aerospace  companies  in  the  late  1960s 
and  early  1970s. 

• Spinoffs  have  heavily  emphasized  remote  batch  because  that  was  their 
original  service  capability:  this  was  due  to  the  requirements  to  service 

their  parent  organizations.  Frequently  they  had  remote  locations  and  exten- 
sive remote  computing  needs,  some  of  which  were  being  met  through  timesharing. 

New  spinoffs  will  continue  the  remote  batch  market  emphasis.  The 
revenue  figures  shown  in  Exhibit  VI-U  do  not  include  the  revenues  which 
spinoffs  receive  from  their  parents. 


2.  IBM  COMPUTERS  ACCOUNT  FOR  ALMOST  HALF  OF  REMOTE  BATCH  REVENUES 

• Because  of  the  dominance  of  spinoffs  in  the  remote  batch  market  and 
their  predominant  use  of  IBM  computers,  hh%  of  the  remote  batch  processing 
in  1975  will  be  on  IBM  computers,  as  shown  in  Exhibit  VI-5.  This  is 
primarily  for  business  processing. 

• The  next  greatest  use  (27$)  is  on  CDC  computers,  primarily  from  CDC 
itself  as  a vendor  and  spinoffs.  Aerospace  companies  are  the  spinoffs 
with  the  in-house  requirements  for  CDC  computers. 

• Two  companies,  UCC  and  CSC  account  for  almost  all  of  the  Uni vac-based 
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EXHIBIT  VI-1* 


SPINOFFS'  1975  REMOTE  COMPUTING  SERVICES 
REVENUES  IN  THE  U.S. 


COMPANY 

REMOTE 

BATCH 

INTERACTIVE 

DATA 

BASE 

TOTAL 

GE 

5 

80 

85 

Me  AUTO 

36 

lit 

50 

BCS 

10 

5 

1 

16 

GRUMMAN 

3 

5 

8 

MMDS 

5 

5 

LITTON 

5 

3 

8 

ACTS 

2 

2 

It 

GTE 

30 

30 

BUNKER  RAMO 

30 

30 

UCS 

18 

18 

XEROX 

20 

20 

COMPUTERISTICS 

6 

6 

WES TINGH OUSE 

5 

1 

6 

IDC 

9 

3 

12 

INS  CO 

5 

2 

7 

SUB-TOTAL 

100 

1U1 

6b 

305 

OTHER 

20 

29 

1 6 

65 

TOTAL 

120 

170 

80 

370 

($  MILLIONS) 
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EXHIBIT  VI-5 


1975  REMOTE  BATCH  REVENUES  BY  COMPUTER  MAKE 


COMPUTER 

MAKE 

SPINOFFS 

COMPUTER 

MANUFACTURERS 

INDEPENDENTS 

OTHER 

TOTAL 

IBM 

70 

10 

38 

5 

123 

CDC 

35 

25 

10 

5 

75 

UN I VAC 

2 

2 

30 

5 

39 

HONEYWELL 

8 

3 

k 

1 

16 

BURROUGHS 

3 

3 

3 

1 

10 

NCR 

7 

1 

1 

9 

DEC 

2 

2 

1 

5 

XDS 

2 

1 

3 

TOTAL 

120 

50 

90 

20 

280 

($  MILLIONS) 
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remote  batch  revenues.  These  consitute  lU/S  of  the  total 


• The  remaining  remote  batch  revenues  are  largely  deferred  run  on 
timesharing  computers,  although  Burroughs  and  Honeywell  computers  do  have 
some  standard  remote  batch  revenues. 
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c. 


COMPETITIVE  MARKET  FACTORS 


1.  MINICOMPUTERS  ARE  AN  ADJUNCT  TO  REMOTE  BATCH  SERVICES 

• Of  the  respondents  to  the  survey,  none  viewed  minicomputers  as 
competition  to  remote  batch  services  at  the  moment.  Several  users  had 
done  extensive  studies  on  replacing  the  services  with  minis,  and  rejected 
them. 

• A potential  use  of  minis,  is  in  the  interactive  part  of  the  process 
for  large  users.  For  example,  one  government  agency  was  going  to  put  a 
Prime  computer  as  a front  end  for  the  interactive  portions  of  its 
engineering  design  applications.  An  advantage  of  this  arrangement  was 
the  ability  to  interact  with  the  in-house  Honeywell  6000  and  the  vendor's 
CDC  hardware. 

• Vendors  regarded  the  advent  of  the  mini,  in  a positive  light. 

• A small  computer,  such  as  a HP  2000  or  System  3,  was  being  used  by 
several  remote  batch  users  to  perform  some  standard  applications  processing. 
In  these  cases  the  remote  system  is  used  for  the  more  complex  problem  and 
volume  transaction  processing. 


2.  TREND  TO  IN-HOUSE  PROCESSING 

• As  shown  in  Exhibit  VI-6,  remote  batch  users  in  the  scientific  and 
engineering  area  regard  an  in-house  computer  as  slightly  more  competitive 
than  business  users. 
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EXHIBIT  VI-6 


IN-HOUSE  COMPUTER  AS  COMPETITION  TO  REMOTE  BATCH  SERVICES 


BY  USER  TYPE 

SCIENTIFIC  & 
ENGINEERING 

YES 

9 

NO 

6 

BUSINESS 

YES 

8 

NO 

11 

FEDERAL 

GOVERNMENT 

YES 

2 

NO 

3 

TOTAL 

YES 

19 

NO 

20 

1 1 ( h 

5 10  15  20 

NUMBERS  OF  ANSWERS  TO  THE  QUESTION  'DOES  AN  IN-HOUSE  SYSTEM 
REPRESENT  COMPETITION  TO  R/B  SERVICES?' 
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EXHIBIT  VI-7 


IK-HOUSE  COMPUTER  AS  COMPETITION  TO  REMOTE  BATCH  SERVICES 

BY  COMPUTER  STATUS 


NUMBERS  OF  ANSWERS  TO  THE  QUESTION  'DOES  AN  IN-HOUSE  SYSTEM 
REPRESENT  COMPETITION  TO  R/B  SERVICES?' 


- 123  - 


INPUT 


• However,  the  real  difference  in  perception  of  the  competition  is 
shown  in  Exhibit  VI-7,  which  shows  that  remote  batch  users  without  a 
computer  are  unlikely  to  consider  getting  a computer  to  replace  the 
services,  while  over  70$  of  remote  batch  users  which  already  have  a com- 
puter regard  the  in-house  computer  as  powerful  competition  to  the  services. 

• In  terms  of  comparison  with  timesharing  users,  the  responses  of  the 
remote  batch  users  with  the  in-house  computer  probably  more  nearly  parallel 
the  expected  timesharing  user’s  response. 

• It  is  important  that  almost  90$  of  the  respondents  who  did  not  have 
a computer  considered  that  an  in-house  system  did  not  even  represent  com- 
petition, let  alone  that  a system  would  replace  the  service. 

3.  TECHNOLOGY  DEVELOPMENTS  WILL  BENEFIT  REMOTE  COMPUTING  SERVICES 

• The  introduction  of  the  3850  and  equivalent  mass  storage  devices 
will  significantly  benefit  all  aspects  of  remote  computing  services. 

They  will  allow  for  cheaper  storage  for  most  applications  data.  Also 
the  user  will  be  able  to  increase  the  size  of  the  data  bases  that  can  be 
economically  kept  ’on-line’  by  an  order  of  magnitude.  Most  applications 
will  allow  for  several  seconds  to  be  used  on  'sign-on'  to  bring  the  file, 
or  portion  of  the  file,  required  to  disk  storage  for  immediate  access. 

• Higher  speed  printers  at  more  reasonable  cost  will  make  volume  output 
cheaper  at  the  user's  site,  instead  of  having  to  go  through  the  vendor's 
local  office.  To  support  this,  however,  higher  line  speeds  will  be 

requi red. 
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• Vendors  considered  that  remote  batch  terminals  would  have  to  come 
down  in  cost  to  at  least  half  their  current  price  in  order  to  significantly 
expand  the  market  down  to  the  'timesharing*  account  at  the  $1000  per  month 
level.  Remote  batch  users  generally  operate  at  a minimum  of  $3K  per  month 
in  order  to  justify  a batch  terminal. 

• The  advent  of  intelligent  terminals  and  terminals  with  local  storage 
such  as  diskettes  and  tape  cassettes,  has  changed  the  nature  of  applications 
related  processing.  It  is  going  to  become  increasingly  difficult  to  call 

an  application  'remote  batch'  or  'on-line*  because  it  will  have  both  modes 
used  at  different  times  in  different  ways. 

However,  there  will  be  portions  of  the  market  dependent  on  very  cheap, 
'dumb'  terminals  which  will  stay  as  pure  interactive  mode,  and  other  por- 
tions using  minis,  for  all  the  interactive  components  and  data  entry, 
which  will  be  pure  remote  batch. 

• Reduction  in  communications  costs  and  widespread  provision  of  high 
speed  networks  will  encourage  use  of  remote  computing  services.  Basically 
the  price  will  drop  enough  to  bring  in  smaller  accounts  from  the  small 
and  medium  size  user. 

• The  continuing  movement  to  CRT  terminals  and  graphics  terminals 
means  that  vendors  will  have  to  offer  'high  speed'  (H8OO/96OO  baud)  inter- 
active as  well  as  high  speed  batch  capabilities  in  order  to  compete  with 
in-house  systems. 

• Industry  and  applications  specialized  terminals  will  replace 
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generalized  terminals.  These  will  give  more  functional  capability  by 
industry/application  at  a lower  cost;  this  will  lower  thresholds  for  user 
entry.  The  advent  of  micro-processors  makes  this  possible. 

Remote  computing  services  vendors  offering  applications  specialized 
services,  such  as  TRW,  National  Data,  XCS,  and  Keydata,  will  increasingly 
specify  the  characteristics  of  the  terminals  they  need  to  terminal  manu- 
facturers. This  will  serve  as  a further  'lock  in'  to  a vendor's  service: 
it  will  also  mean  that  it  will  have  an  increasing  share  of  its  revenues 
from  the  mark-up  on  hardware. 

k.  IBM  DEVELOPMENTS  ARE  CRITICAL  FOR  REMOTE  BATCH  VENDORS 

• Because  of  the  preponderance  of  IBM-based  revenues  in  remote  batch 
markets,  future  announcements  by  IBM  will  have  more  impact  on  them  than 
on  timesharing  or  data  base  services. 

- Business  users  surveyed  gave  strong  preference  for  IBM  mainframe 

capability,  and  there  is  no  doubt  that  this  will  be  an  advantage  in 
several  of  the  remote  batch  marketplaces,  notably  the  computer 
substitution  and  the  computer  enhancement  market. 

— The  latter  case  is  where  a vendor  will  provide  certain  applica- 
tions not  easily  handled  by  the  in-house  computer,  because  of 
storage  or  communications  requirements,  for  example:  there  will 

usually  be  major  interface  requirements  for  data  exchange  and 
equipment  and  software  compatibility  will  greatly  enhance  the 
likelihood  of  success  for  a vendor.  An  example  would  be  a major 
order  entry  system  that  Compute ri sties  is  installing  for  over 
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200  offices  of  a large  mining  and  manufacturing  company 


• Vendors  will  find  it  necessary  to  support  the  communications 
protocols  and  access  languages  that  IBM  introduces  within  its  overall 
communications  system  plans.  It  may  be  possible  to  emulate  these  through 
the  use  of  mini  and  micro  processors,  but  this  will  cause  a significant 
problem  for  vendors  which  are  not  solely  IBM-based. 

• The  importance  of  IBM  operating  systems  developments  has  already 
been  mentioned.  The  bringing  together  of  the  remote  batch  and  interactive 
modes  will  be  a major  benefit  to  IBM-based  vendors,  when  the  software  is 
made  to  work. 

• Support  of  the  IBM  data  base  management  and  retrieval  language  systems 
will  be  a major  requirement  for  remote  batch  revenue  generation.  IMS  and 
CICS,  while  lacking  in  function  and  performance  compared  to  other  systems, 
are  nevertheless  in  the  mainstream  of  IBM  developments. 

• The  midrange  of  IBM  computers,  from  the  System/32  to  the  System  370/135, 
appears  to  be  where  IBM  will  emphasize  computer  enhancement  in  the  late 
1970s.  It  will  replace  the  in-house  monolithic  computer  by  3790  or 
System/ 32  work  stations  connected  to  its  own  large  computers.  This 

should  be  the  prime  target  area  for  computer  substitution  and  enhancement 
by  the  remote  batch  vendors. 

• Price /performance  characteristics  of  IBM  processors,  main  storage, 
peripheral  storage  and  input/output  will  improve  relative  to  the  compe- 
tition for  transaction  processing,  as  opposed  to  problem  solving.  This 
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will  make  their  equipment  even  more  useful  for  remote  batch  work;  the 
share  of  the  remote  batch  market  dependent  on  IBM  mainframes  will  therefore 
increase. 

• Provision  of  improved  capabilities  for  remote  batch  from  IBM  will 
increase  competition  in  the  remote  computing  market.  Organizations  with 
industry /appli cations  expertise  will  find  networks  easily  available 
from  Tymshare,  Telenet,  GTE,  and  others  and  will  be  able  to  obtain,  or 
already  have,  the  necessary  remote  computing  hardware  and  operating 
system  from  IBM. 
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VII.  STRATEGIES  AND  OPPORTUNITIES 


INPUT 


VII.  STRATEGIES  AND  OPPORTUNITIES 


There  are  two  major  identifiable  remote  batch  markets:  business, 

and  scientific  and  engineering.  In  addition,  the  Federal  Government 
market  has  certain  unique  characteristics  which  set  it  apart.  The  first 
of  the  following  sections  contains  recommendations  which  are  generally 
applicable;  recommendations  for  individual  markets  are  discussed 
thereaf  ter. 
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A. 


GENERAL  RECOMMENDATIONS 


• Vendors  presently  offering  remote  batch  services  to  the  scientific 
and  engineering  market  should  continue  to  emphasize  their  present  services 
while  moving  into  the  business  market.  (See  Section  B below.) 

• Vendors  presently  offering  remote  batch  services  to  the  business 
market  should  put  all  of  their  efforts  into  that  market. 

• Organizations  considering  entry  into  either  of  these  markets  should 
concentrate  their  efforts  on  the  business  market,  although,  depending 
upon  target  industries,  this  implies  a certain  degree  of  scientific  and 
engineering  capability. 

• All  vendors  in  the  remote  computing  markets  must  have  systems  offering 
integrated  remote  batch  and  interactive  capabilities. 

• Vendors  should  develop  techniques  whereby  intelligent  terminals  and 
minicomputers  are  integrated  into  their  service  capabilities.  Vendors 
should  offer  this  capability  rather  than  waiting  for  users  to  develop  it 
themselves  so  that  the  service  company  can  retain  account  control  and  as 
much  of  the  processing  as  possible.  A well  integrated  system  will  also 
be  a cost-effective  competitor  to  in-house  systems.  Some  scientific  and 
engineering  users  are  already  using  such  systems  of  their  own  design;  more 
will  certainly  follow.  As  has  been  characteristic  of  developments  within 
the  computer  industry,  the  business  users  will  follow  in  greater  numbers. 


-130- 


INPUT 


• Vendors  should  develop  the  necessary  software  and  hardware  features 
to  support  large  data  bases,  both  private  and  shared.  Software  supported 
should  include  a spectrum  of  data  base  management  software,  particularly 
IBM  'standards'  such  as  IMS.  It  will  be  a competitive  advantage  to  be 
able  to  use  the  same  data  base  management  software  on  the  central  computer 
and  distributed  computers  in  the  network. 

• Sales  efforts  should  be  aimed  primarily  at  new  users  rather  than 
trying  to  unhook  current  remote  batch  users.  It  is  not  practical  to  take 
away  business  based  upon  price  and,  unless  service  deteriorates,  users 
will  generally  stay  with  their  present  vendors. 

• "Service"  is  of  prime  importance  to  users  and  is  defined,  in  this 

order,  as:  1)  reliability,  2)  turnaround,  and  3)  responsive  user  support. 

Systems  design  and  development  should  emphasize  reliability  and  maintain 
acceptable  levels  of  turnaround.  Technical  support  personnel  should  be 
readily  available  to  the  users  as  required  and  should  include  people  who 
are  knowledgeable  on  applications  as  well  as  general  systems  use. 

• Present  sales  forces  are  not  considered  by  the  users  to  have  adequate 
knowledge  of  the  products  and  services  they  are  selling.  Vendors  of  remote 
batch  services  should  make  regular  efforts  to  develop  and  maintain  a high 
level  of  product  knowledge  within  the  sales  force. 

• It  would  be  a competitive  advantage  for  the  sales  force  to  be  able  to 
understand  the  user  needs.  This  implies  an  understanding  of  the  users' 
business  and  the  application  of  the  vendor's  services  to  those  needs. 
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B. 


SCIENTIFIC  AND  ENGINEERING  MARKET 


• Vendors  in  this  market  should  continue  to  offer  state-of-the-art, 
high  technology  applications  with  user-oriented  interfaces. 

• Scientific  and  engineering  oriented  vendors  should  penetrate  the 
business  market  by  marketing  application  programs  which  take  advantage 
of  the  hardware  strengths  of  their  large-scale  scientific  computers. 

In  particular,  vendors  should  emphasize  analytical  problem  solving  using 
modelling  and  simulation  tools.  In  addition,  applications  such  as 
detailed  scheduling,  tactical  planning,  and  resource  optimization  require 
the  type  of  processing  resource  that  these  vendors  offer. 

• In  order  to  further  penetrate  the  business  market,  vendors  must 
develop  the  capability  to  handle  the  file  I/O  requirements  of  the 
business  users.  In  addition,  a variety  of  standard  business  application 
software  must  be  made  available. 

• There  is  some  indication  that  graphics  will  increase  in  importance 
in  at  least  the  area  of  structural  engineering  and  design.  Therefore, 
vendors  should  keep  abreast  of  user  needs  in  this  area  and  be  prepared 
to  aggressively  market  graphics  should  the  demand  become  apparent. 
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C.  BUSINESS  MARKET 


• For  maximum  penetration  of  this  market  vendors  should  offer  services 
on  IBM  mainframes.  This  is  particularly  true  for  the  computer  substitution 
segment  of  this  market  but  also  valuable  in  the  marketing  of  applications 
processing.  While  there  are  many  business  applications  for  which  the 
mainframe  type  used  is  irrelevant,  business  users  would  prefer  IBM 
because  of: 

- Compatibility 

- Perceived  reduction  of  risk,  and 

- Availability  of  personnel  and  software  packages. 

• Officers  of  service  companies  should  try  to  persuade  officers  of 
large  computer  users  to  put  the  in-house  D.P.  department  on  P&L  basis 
and  allow  user  groups  (departments  or  divisions)  to  select  between  the 
in-house  and  the  service  alternatives. 

• Develop,  acquire,  or  joint  venture  specific  business  application 
systems  based  upon  company  expertise  and  processing  strengths;  value 
pricing  should  be  used  whenever  possible. 

• The  computer  substitution  market,  which  offers  the  greatest  potential 
in  the  remote  computer  services  area,  should  be  approached  with  a combined 
package  of: 

- Integrated  interactive  and  remote  batch  capabilities, 

- Range  of  DB/FM  systems  from  an  ad  hoc  report  writer  up  to  a 
large  scale  file  management  system, 
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- Data  communications  network, 

- Variety  of  "canned"  application  programs  for  general  business 
use,  and 

- Contract  consulting  and  programming  staff 

• Good  prospects  for  the  computer  substitution  approach  are: 

Companies  with  sales  of  from  $5  million  to  $100  million  with 
emphasis  in  the  range  of  $10  million  to  $50  million  range. 

High  technology  and/or  growing  companies, 

- Companies  with  some  need  for  large  scale  computer  capabilities 
(files,  CPU,  network),  and 

An  agreeable  D.P.  manager  or  other  decision  maker. 

• Computer  substitution  sales  will  require  a separate  sales  force  from 
the  one  selling  the  variety  of  traditional  remote  computer  processing 
services.  In  addition,  application  programs  may  also  require  separate 
sales  people.  Industry  specialized  services,  such  as  McAuto's  hospital 
services  program,  require  separate  sales  and  support  forces. 
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D. 


FEDERAL  GOVERNMENT  MARKET 


• The  GSA  ADR  Teleprocessing  Services  Contract  Program  is  a mechanism 
for  obtaining  an  'industry'  discount  from  vendors  and  enhancing  GSA's 
control  in  this  area.  Vendors  will  not  obtain  revenues  through  simply 
being  on  the  approved  contractor  list;  they  must  sell  strongly  and 
competitively  to  obtain  federal  government  market  share. 

• Specialized  vendors  will  be  able  to  sell  to  agencies  outside  the 
GSA  contract.  They  should  therefore  only  bid  the  GSA  contract  if  they 
determine  the  profitability  of  the  increased  amount  of  business  they  will 
be  able  to  competitively  obtain  outweighs  the  reduction  of  profitability 
on  the  specialized  business  which  they  would  obtain  anyway. 

• Costs  of  marketing  to  the  federal  government  will  be  high  and 
competition,  led  by  CSC,  will  be  severe.  Vendors  should  carefully 
evaluate  the  return  on  the  investment  to  obtain  GSA  contract  approval 
and  to  develop  the  federal  market  compared  with  the  return  on  the 
investment  to  develop  other  markets.  If  a vendor  decides  to  bid  the 
GSA  contract,  sales  effort  should  then  be  applied  to  a limited  selection 
of  agencies  to  achieve  market  penetration. 
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APPENDIX 


INTERVIEW  BASE 


Catalog 

Number 

Major 

Use 

Industry 

Company 

Size* 

Geographic 

Region 

RRB1 

SCI  & ENG 

UTIL,  R&D 

M 

W 

RRB3 

H 

CONSTR. 

VL 

W 

RRB4 

fl 

MFG . 

S 

W 

RRB5 

tt 

MFG. 

VL 

w 

RRB19 

If 

UTIL. 

VL 

SE 

RRB20 

If 

MFG. 

VL 

MW 

RRB22 

II 

MFG. 

M 

W 

RRB23 

II 

MFG. 

M 

W 

PRB1 

ft 

MFG. 

VL 

MW 

PRB5 

II 

MFG. 

VL 

W 

JRB4 

ft 

UTIL. 

L 

SU 

CRB  3 

II 

MFG. 

L 

SE 

CRB5 

If 

UTIL. 

VL 

NE 

CRB8 

II 

MFG. 

VL 

NE 

CRB  9 

II 

MFG. 

VL 

MW 

RRB2 

BUSINESS 

ENG.  SVC. 

S 

W 

RRB9 

It 

PUBL. 

L 

NE 

RRB21 

It 

MFG. 

VL 

W 

RRB24 

If 

MFG. 

M 

w 

RRB25 

II 

INS. 

S 

w 

RRB26 

ft 

MFG. 

VL 

w 

PRB2 

! if 

STATE  GOVT 

- 

MW 

PRB3 

n 

MFG . 

s 

MW 

PRB4 

VI 

ENG.  SVC. 

M 

W 

PRB8 

ii 

MFG. 

L 

MW 

JRB1 

it 

MFG. 

S 

W 

JRB2 

ti 

CITY  GOVT 

- 

W 

JRB6 

it 

SERVICE 

S 

W 

CRB1 

it 

BANK 

VL 

NE 

CRB  5 

ii 

INS. 

VL 

NE 

CRB  7 

tt 

MFG. 

L 

NE 

CRB11 

tt 

UTIL. 

VL 

NE 
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Ca talog 
Number 

Mai  or 
Use 

Indus  try 

Company 

Size* 

Geographic 

Region 

PRB6 

FED  GOVT 

WASH  D.C. 

PRB7 

- 

— 

tl 

PRB9 

- 

— 

If 

PRB10 

- 

— 

ff 

PRB11 

- 

- 

ff 

CRB4 

NONE 

BANK 

VL 

NE 

RN06 

ft 

INS. 

VL 

NE 

RN08 

It 

RET. 

VL 

MU 

RNOll 

ff 

RET. 

VL 

MW 

RN014 

fl 

MFG. 

VL 

MW 

RN015 

If 

UTIL. 

L 

SE 

RN017 

ft 

STATE  GOVT 

- 

SW 

RTS  7 

T/S  ONLY 

MFG. 

VL 

MW 

RTS  10 

It 

MFG. 

L 

NE 

RTS  12 

ff 

MFG. 

VL 

SW 

RTS  13 

ff 

MFG. 

L 

NE 

RTS  16 

ft 

FIN. 

L 

MW 

RTS  18 

ff 

MFG. 

VL 

SE 

CRB10 

SPIN-OFF 

INS. 

VL 

NE 

CRB12 

- 

R&D 

— 

MW 

CRB13 

- 

- 

— 

SE 

JRB3 

VENDOR 

BANK 

L 

SW 

JRB5 

VENDOR 

BANK 

M 

SE 

SUMMARY:  SCI  & ENG 

BUSINESS 
FED.  GOV'T 
NON-USERS 
T/S  ONLY 
OTHERS 


15  (Interviews) 
17 

5 
7 

6 
5 


TOTAL:  55 


* COMPANY  SIZE  IN  $ MILLIONS  IN  ANNUAL  SALES  OR  EQUIVALENT: 

S = $ 0 - 20  MM 

M = 20  - 100  MM 

L = 100  - 500  MM 

VL  = > 500  MM 
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CONFIDENTIAL 


INPUT  QUESTIONNAIRE 


CATALOG.  NO. 


REMOTE  BATCH  (R/B)  USER'S  QUESTIONNAIRE 


CURRENT  USAGE 


1 Why  do  you  use  R/B  services? 


2.  What  vendor  do  you  use? 

Why  did  you  choose  them?  Are  you  satisfied? 


3.  What  per  cent  of  your  current /future  R/B  services  usage  would  you 


• 

characterize  as: 

(a)  Conversion  from  batch  services  bureau 

Current 

°L 

fa 

Future 

% 

(b) 

Conversion  from  timesharing  services. 

% 

% 

(c) 

Conversion  from  batch  in-house 

% 

% 

• 

(d) 

New  applications 

% 

% 

(e) 

Overflow  processing 

% 

% 

(f) 

Other  (specify) 

% 

% 

k.  What  percent  of  your  current/future  usage  is  pure  remote  batch  vs. 
that  which  has  some  interactive  component  (e.g.  CRJE,  WYLBUF.)? 


Current 

Future 

• 

Pure 

l 

al 

ft 

Component 

% 

% 
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What  percent  of  your  current /future  usage  is  remote  data  entry  vs. 
remote  job  entry? 

Current  Future 

Remote  data  entry  % % 

Remote  job  entry  % % 

What  percent  of  current/future  remote  batch  service  usage  is? 

Current  3 Years 

Your  own  programs  % % 

Vendor  supplied  programs  % % 

(a)  What  percent  of  this  usage  requires  or  will  require  a Data  Base/ 

File  Management  (DB/FM)  system? 

Current  3 Years 

% % 

(a)  What  applications  are  presently  being  run  on  R/B  services? 

(b)  What  applications  are  planned  for  R/B  services? 

(c)  For  what  applications  would  you  consider  R/B  services? 

(DESCRIBE  ON  FOLLOWING  TABLE) 


7.  (cont.) 


CATALOG.  NO. 


APPLICATION 

VENDOR /USER 
WRITTEN 

NEW  OR 
CONVERSION 

WHY  R/B  SERVICE? 

CURRENT 

PLANNED 

POSSIBLE 

-140- 


8.  With  regard  to  your  current  R/B  services  use: 


9. 


10. 


(a) 

How  much 

core  to  your  programs 

requi  re? 

Typical 

Max. 

(b) 

How  large 

are  your  files? 

Typical 

Max. 

• 

(c) 

What  file 

organization  do  you 

use? 

(d)  How  frequently  do  you  execute  these  jobs? 


(e)  What  percent  of  your  jobs  require  turnaround  of: 

2 hours  % 

2-8  hours  % 

Next  day  % 


(f)  How  much  execution  time  is  required?  Typical 

Max. 


Have  you  considered  using  minis  as  an  alternative  to  R/B  service 
usage?  If  yes,  what  was  the  result? 


Have  you  considered  using  minis  in  conjunction  with 


a R/B  service? 
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11.  What  developments  will  increase  or  decrease  your  usage  of  R/B  services? 


TECHNICAL  USAGE 


12.  What  are  your  in-house  computer  mainframes,  operating  systems, and 
DB/DC  systems?  What  are  those  of  your  R/B  service  vendor? 


HARDWARE 

OPERATING  SYSTEMS 

DB/DC 

IN-HOUSE 

VENDOR 

13.  Is  it  a requirement  for  the  R/B  vendor  to  have  that  particular: 

(a)  Computer  mainframe?  

(b)  operating  system?  


(c) 

DB/DC 

system? 

0 

(d) 

other 

software  features  or  options? 

(e) 

other 

hardware  (e.g.  COM  PLOTTER,  3850)? 

14.  What  languages  are  required? 


(a)  For  which  languages  do  you  require  some  interactive  capability? 


15. 


Do  you  require  absolute  compatibility  with  the  computer  vendor's 
software? 


(a)  To  what  extent  are  missing  features  or  capabilities  tolerable? 

( b ) Are  so-called  improvements  in  functions  or  performance: 

Unacceptable  Acceptable  Preferable  


16.  Is  your  usage  of  R/B  services  dependent  upon  the  availability  of  a 
communications  network  which  can  support  input  and  output  to  and 
from  different  cities?  Which  cities? 


IT.  Is  current  access  to  the  vendor's  R/B  system  via: 

(a)  Local  dial?  (b)  Long  distance  dial?  (c)  Leased  line? 

If  (c):  Who  is  responsible?  Vendor  User  
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18.  Are  there  any  particular  telecommunications  access  methods  which  you 
require? 


19.  What  devices  are  currently /will  be  used  as  R/B  terminals?  At  what 
baud  rates? 


Make /Model  - 

Baud  Rates 

Transmission 

Protocol 

Current 

Future 

20 


Do  you  have  any  other  communications  requirements  related  to  R/B 
service  usage? 


MARKETING 


21. 


Rank  the  following  factors  from  1 to  10  ( 1 = unimportant,  10 
in  your  selection  of  a vendor  of  R/B  services: 


critical) 


Factor 


Comments 


(a)  Proximity  to 
vendor. 

(b)  Network 
availability. 

(c)  Vendor  Hardware/ 
Software  Systems 

(d)  Vendor  Applica- 
tions . 


(e)  Tech.  Support/ 
Training. 

(f)  Price 

(g)  Other 


22.  Which  of  the  following  pricing  methods  are  currently  being  used? 


Which  would  you 

prefer? 

Method 

Current 

Prefer 

Comments 

By  machine  resources 
By  Transaction 
By  No.  of  records 
Long  term  contract 
Quantity  discount 

(See  next  page) 
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22.  (Cont.) 


CATALOG.  NO. 


Other: 


Method 

Current 

Prefer 

Comments 

22(a)  What  is  the  term  of  your  contract? 

23.  Assuming  similar  services  would  you  switch  vendors  if  smother  vendor 
offered  service  at: 

(a)  A higher  price? . How  much  higher?  . 

Why? 


(b) 


The  same  price: 

10$  less  

20%  less  

30$  less  

40$  less  


50$  less 


24. 


Under  what  conditions, 
vendor? 


other  than  price. 


would  you  switch  to  a new 


25. 


For  an  otherwise  similar  service,  what  price  difference  would  you 
expect  between  Timesharing  and  Remote  Batch? 


26. 


In  hours  per  week. 


about  how  much  technical 


support  do  you  require? 


(a) 


How  much  more  or  less  do  you  think  this  is  than  for  an  equivalent 
amount  of  T/S? 


2?.  What  characteristics  do  you  look  for  in  a salesperson  of  R/B  services? 


28. 


Who  in  your  company  makes  decisions 
servi ces? 


regarding  the  purchase  of  R/B 
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29. 


About  how  much  money  per  month  do  you  currently/next  year/3  years 
spend  for  R/B  computer  services? 


Current 
Next  year 
3 years 


$ 

$ 

$ 


30. 


Does  an  in-house  system  represent  competition  for  R/B  services? 

Yes  _____  No  

(a)  Under  what  conditions  will  an  outside  R/B  service  be  used? 


31. 


What  advice  would  you  give  to  a vendor  of  R/B  computer  services? 
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